From hans at guardianproject.info Thu Mar 1 02:29:44 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 29 Feb 2012 17:29:44 -0800 Subject: gpgme android build fails looking for /usr/local/lib/libgpg-error.la Message-ID: <4B24F294-2227-45EC-A380-94432741DE07@guardianproject.info> So gpgme is building fine on Android using the attached patch, it just doesn't finish linking to libgpg-error because the build system is convinced that its in /usr/local/lib, where it is definitely not. I tried to trace it a bit, but no luck yet. Any ideas where this is being set? To see how I'm building gpgme, check out the gpgme-build target in this Makefile, that will show the ./configure flags, etc. https://github.com/guardianproject/gnupg-for-android/blob/master/external/Makefile Here's the error in question: libtool: link: /usr/local/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-ar cru .libs/libgpgme.a conversion.o get-env.o data.o data-fd.o data-stream.o data-mem.o data-user.o data-compat.o signers.o sig-notation.o wait.o wait-global.o wait-private.o wait-user.o op-support.o encrypt.o encrypt-sign.o decrypt.o decrypt-verify.o verify.o sign.o passphrase.o progress.o key.o keylist.o trust-item.o trustlist.o import.o export.o genkey.o delete.o edit.o getauditlog.o opassuan.o passwd.o engine.o engine-gpg.o status-table.o engine-gpgsm.o assuan-support.o engine-assuan.o engine-gpgconf.o engine-g13.o vfs-mount.o vfs-create.o gpgconf.o posix-util.o posix-sema.o posix-io.o dirinfo.o debug.o gpgme.o version.o error.o ath.o stpcpy.o libtool: link: /usr/local/android-ndk/toolchains/arm-linux-androideabi-4.4.3/prebuilt/linux-x86/bin/arm-linux-androideabi-ranlib .libs/libgpgme.a /bin/sed: can't read /usr/local/lib/libgpg-error.la: No such file or directory libtool: link: `/usr/local/lib/libgpg-error.la' is not a valid libtool archive .hc -------------- next part -------------- An HTML attachment was scrubbed... URL: From Mustrum at mustrum.net Thu Mar 1 14:25:45 2012 From: Mustrum at mustrum.net (Mustrum) Date: Thu, 01 Mar 2012 14:25:45 +0100 Subject: Smartcards and 1.4 Message-ID: <1f568f59-b7c3-4f6a-8840-760c934df583@email.android.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Jan 20, 2012, 3:26 AM Werner Koch wrote: >I wonder why you use 1.4 on Windows. May be just because t's much easier to get an updated binary package for 1.4. 1.4.12 binaries are available from gnupg.org with every release. 2.0 binaries are only provided within gpg4win (last release: 2011-03-15) Regards, Mustrum. -----BEGIN PGP SIGNATURE----- Version: APG v1.0.8 iQIVAwUBT0942Ey6/YZf1YOeAQrANQ/9Eb5clN7lpwrBwA8kdUzh4oQSCoKd/vBW jQ4wzEB78VwYMw46utV7jO81SVycIASNwmNETx0HNBNERcvvNbgBX0wo3N1/HKUs vwxTkiCdx3ottOJ+omufSHhcqauU4SNdCOoHajhGSu0XyVgzKswrGftJmATpb7h6 09Qo3tWe2Kvt9u5IGk1Sr5+0AFOiuR8J6yRluIiqZ3FwK2lvQ3TwCOWaY5zI2Hgw sbvb5QIZd/34KnGSvO3uPAweGa+48lAKn4fWWjV/DHNB+0D0GTRmwWUcypKhVvEP jZ09aaZ46i/2zxKUFy9c2WZSt8BGF2u9xYDtQ47FsXGabu1CSJ4wDCz8jjUk3VdP QOX4gHTElVpZP06dBHyD5Nn1uSlXWNtTphFsA4UibZrMb075J+/u5fvUi9zcJUNw 5sAzGkBeLVLmnl8S8O42bA4MNGWUIhxK+i5dlsZEb4VNKgRsYkeCAlXaOQsm5eTu sHKjGABR7Fh7+iq6UerjvpBFE1ZVjdnegcb57DOayHImdFufvmqDk8kHNh+AamdF dULfLC5atQbp5gi8rK8TeamMNgNftXhAwyCm1EIye3nXYd1m70t2zZMw6AXheMAd Hf79224zzj0JoG+g0IRW5WkgSUpfoLKSnkNkhyPx1NWy/uXi7e3DhfTgJjB6OLFb 10TQ8BvDFo4= =vIet -----END PGP SIGNATURE----- From marcus.brinkmann at ruhr-uni-bochum.de Thu Mar 1 23:41:12 2012 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 1 Mar 2012 23:41:12 +0100 Subject: npth finds pthread_mutex_timedlock() which android does not have In-Reply-To: <4F4D1270.9000405@guardianproject.info> References: <4F42A81F.7080004@guardianproject.info> <4F42C626.4070109@guardianproject.info> <4F4D0190.7030209@ruhr-uni-bochum.de> <4F4D1270.9000405@guardianproject.info> Message-ID: <4F4FFB08.9010205@ruhr-uni-bochum.de> On 02/28/2012 06:44 PM, Hans-Christoph Steiner wrote: > > On 02/28/2012 11:32 AM, Marcus Brinkmann wrote: >> On 02/20/2012 11:16 PM, Hans-Christoph Steiner wrote: >> >>> Turns out there is another issue with npth on Android. npth_yield is a >>> macro for pthread_yield, which Android does not seem to have. I cannot >>> find another confirmation of this besides pthread_yield() not being any >>> headers. >> >> While I find the disregard for standard compliance in Android deeply >> disturbing, in this case the right fix is to remove npth_yield entirely >> (which should have been a function anyway, as it needs to release the >> global lock temporarily). yield is considered harmful, and I changed >> the only place where it is called in gnupg with a sleep (well, there are >> some more calls in the windows CE port which will eventually be taken >> care of). >> >> npth: c30634abebb287f56a6a2480b4bbd2ffc166dd4d >> gnupg: 8f8c6594147608b1021c16fc3561feb96da5d55a > > That's great, I'll try a build right now. I also noticed that you > committing some changes to make pthread_rwlock* optional. Do you think > that will ultimately apply to dirmngr as well? Yeah, but it's not a complete fix yet. The ultimate situation will be to use a simple mutex if rwlocks are not present at all. rwlocks are really just an optimization, and should degrade fine to a standard mutex (the windows port used to do that). > As for Android's standard compliant, it is a bummer. I find it useful > to understand their view on the native side of things when thinking > about this stuff. First off, Android isn't UNIX, its a new thing with a > Linux kernel and some UNIXish stuff (for example, most stuff is in > /system). Then, the original intention is that developers would only > ever work in Java, and they do provide a complete and > standards-compliant Java SDK. It is only because of large developer > demand have they been convinced to open up the underlying C layers for > general development, so now are starting to catch up with standard > compliance there. That sounds like a good explanation of what's going on, thank you. Marcus From hans at guardianproject.info Thu Mar 1 23:42:48 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Thu, 01 Mar 2012 17:42:48 -0500 Subject: gpg-agent seems to be talking to itself a lot Message-ID: <4F4FFB68.7010803@guardianproject.info> I'm in the process of trying to get the whole gnupg 2.1 suite working on Android now I have everything built and deployed. I can do quite a few actions, but not all. I can go "gpg2 --import", "gpg2 --list-keys", "gpg2 --fingerprint", and things like that. In the process of debugging the whole setup, I noticed that gpg-agent seems to be spending a fair amount of time talking to itself. Here's a snippet of the log, note the timestamps: 2012-03-01 20:52:37 gpg-agent[1482] handler 0x523d0 for fd 7 started 2012-03-01 20:52:37 gpg-agent[1482] DBG: chan_7 -> OK Pleased to meet you, process 1482 2012-03-01 20:52:37 gpg-agent[1482] DBG: chan_5 <- OK Pleased to meet you, process 1482 2012-03-01 20:52:37 gpg-agent[1482] DBG: chan_5 -> GETINFO pid 2012-03-01 20:52:37 gpg-agent[1482] DBG: chan_7 <- GETINFO pid 2012-03-01 20:52:37 gpg-agent[1482] DBG: chan_7 -> D 1482 2012-03-01 20:52:37 gpg-agent[1482] DBG: chan_5 <- D 1482 2012-03-01 20:52:37 gpg-agent[1482] DBG: chan_7 -> OK 2012-03-01 20:52:37 gpg-agent[1482] DBG: chan_5 <- OK 2012-03-01 20:52:37 gpg-agent[1482] DBG: chan_5 -> BYE 2012-03-01 20:52:37 gpg-agent[1482] DBG: chan_7 <- BYE 2012-03-01 20:52:37 gpg-agent[1482] DBG: chan_7 -> OK closing connection 2012-03-01 20:52:37 gpg-agent[1482] handler 0x523d0 for fd 7 terminated 2012-03-01 20:53:37 gpg-agent[1482] handler 0x523d0 for fd 7 started 2012-03-01 20:53:37 gpg-agent[1482] DBG: chan_7 -> OK Pleased to meet you, process 1482 2012-03-01 20:53:37 gpg-agent[1482] DBG: chan_5 <- OK Pleased to meet you, process 1482 2012-03-01 20:53:37 gpg-agent[1482] DBG: chan_5 -> GETINFO pid 2012-03-01 20:53:37 gpg-agent[1482] DBG: chan_7 <- GETINFO pid 2012-03-01 20:53:37 gpg-agent[1482] DBG: chan_7 -> D 1482 2012-03-01 20:53:37 gpg-agent[1482] DBG: chan_5 <- D 1482 2012-03-01 20:53:37 gpg-agent[1482] DBG: chan_7 -> OK 2012-03-01 20:53:37 gpg-agent[1482] DBG: chan_5 <- OK 2012-03-01 20:53:37 gpg-agent[1482] DBG: chan_5 -> BYE 2012-03-01 20:53:37 gpg-agent[1482] DBG: chan_7 <- BYE 2012-03-01 20:53:37 gpg-agent[1482] DBG: chan_7 -> OK closing connection 2012-03-01 20:53:37 gpg-agent[1482] handler 0x523d0 for fd 7 terminated 2012-03-01 20:54:37 gpg-agent[1482] handler 0x523d0 for fd 7 started 2012-03-01 20:54:37 gpg-agent[1482] DBG: chan_7 -> OK Pleased to meet you, process 1482 2012-03-01 20:54:37 gpg-agent[1482] DBG: chan_5 <- OK Pleased to meet you, process 1482 2012-03-01 20:54:37 gpg-agent[1482] DBG: chan_5 -> GETINFO pid 2012-03-01 20:54:37 gpg-agent[1482] DBG: chan_7 <- GETINFO pid 2012-03-01 20:54:37 gpg-agent[1482] DBG: chan_7 -> D 1482 2012-03-01 20:54:37 gpg-agent[1482] DBG: chan_5 <- D 1482 2012-03-01 20:54:37 gpg-agent[1482] DBG: chan_7 -> OK 2012-03-01 20:54:37 gpg-agent[1482] DBG: chan_5 <- OK 2012-03-01 20:54:37 gpg-agent[1482] DBG: chan_5 -> BYE 2012-03-01 20:54:37 gpg-agent[1482] DBG: chan_7 <- BYE 2012-03-01 20:54:37 gpg-agent[1482] DBG: chan_7 -> OK closing connection 2012-03-01 20:54:37 gpg-agent[1482] handler 0x523d0 for fd 7 terminated From wk at gnupg.org Sat Mar 3 11:15:08 2012 From: wk at gnupg.org (Werner Koch) Date: Sat, 03 Mar 2012 11:15:08 +0100 Subject: gpg-agent seems to be talking to itself a lot In-Reply-To: <4F4FFB68.7010803@guardianproject.info> (Hans-Christoph Steiner's message of "Thu, 01 Mar 2012 17:42:48 -0500") References: <4F4FFB68.7010803@guardianproject.info> Message-ID: <878vji0z4j.fsf@gnupg.org> On Thu, 1 Mar 2012 23:42, hans at guardianproject.info said: > I'm in the process of trying to get the whole gnupg 2.1 suite working on > Android now I have everything built and deployed. I can do quite a few > actions, but not all. I can go "gpg2 --import", "gpg2 --list-keys", > "gpg2 --fingerprint", and things like that. Great. > In the process of debugging the whole setup, I noticed that gpg-agent > seems to be spending a fair amount of time talking to itself. Here's a Not really, it is only once a minute: /* The timer tick used for housekeeping stuff. For Windows we use a longer period as the SetWaitableTimer seems to signal earlier than the 2 seconds. CHECK_OWN_SOCKET_INTERVAL defines how often we check our own socket in standard socket mode. If that value is 0 we don't check at all. All values are in seconds. */ #if defined(HAVE_W32CE_SYSTEM) # define TIMERTICK_INTERVAL (60) # define CHECK_OWN_SOCKET_INTERVAL (0) /* Never */ #elif defined(HAVE_W32_SYSTEM) # define TIMERTICK_INTERVAL (4) # define CHECK_OWN_SOCKET_INTERVAL (60) #else # define TIMERTICK_INTERVAL (2) # define CHECK_OWN_SOCKET_INTERVAL (60) #endif For CE we disabled it completey because we are sure that we won?t suffer from race conditions. Those may lead on desktop to two agents processes. Two processes don?t harm but it is better to kill the unused one, Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From rose-indorf at gmx.de Sat Mar 3 16:11:26 2012 From: rose-indorf at gmx.de (Sebastian Rose-Indorf) Date: Sat, 3 Mar 2012 16:11:26 +0100 Subject: FAIL: conventional-mdc.test Message-ID: <000901ccf94f$e7d96b20$b78c4160$@de> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 Hello, I've build GnuPG 1.4.12 using MinGW on Windows Vista 64bit. Only one of the checks (make check) faild: conventional-mdc.test. The conventional-mdc.test file in NOT modified. conventional-mdc.test.log says: "gpg: 3DES verschl?sselte Daten gpg: Verschl?sselt mit einer Passphrase cp: cannot stat `0': No such file or directory" Any ideas? Seb. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12-SpecialBuild (MingW32) - GPGrelay v0.962 iD8DBQFPUjSpoNLoClWVo8MRA9ozAJ9qc/ftz0i8E4FQWHXaj04mDETRmgCgi0K5 MxTtktsxegF1hlzZbft9sU8= =DEv4 -----END PGP SIGNATURE----- From wk at gnupg.org Sun Mar 4 11:44:16 2012 From: wk at gnupg.org (Werner Koch) Date: Sun, 04 Mar 2012 11:44:16 +0100 Subject: FAIL: conventional-mdc.test In-Reply-To: <000901ccf94f$e7d96b20$b78c4160$@de> (Sebastian Rose-Indorf's message of "Sat, 3 Mar 2012 16:11:26 +0100") References: <000901ccf94f$e7d96b20$b78c4160$@de> Message-ID: <87obscwsqn.fsf@gnupg.org> On Sat, 3 Mar 2012 16:11, rose-indorf at gmx.de said: > I've build GnuPG 1.4.12 using MinGW on Windows Vista 64bit. As you know, building on Windows is not supported. > "gpg: 3DES verschl?sselte Daten > gpg: Verschl?sselt mit einer Passphrase > cp: cannot stat `0': No such file or directory" I can't see the use of cp in this test, but I did not looked closely. To debug this you should add a set -x to the top of the test script. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From marcus.brinkmann at ruhr-uni-bochum.de Tue Mar 6 00:01:08 2012 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 6 Mar 2012 00:01:08 +0100 Subject: Android does not have pthread_rwlock*, npth wants them In-Reply-To: <4F4830F7.9040601@guardianproject.info> References: <4F4830F7.9040601@guardianproject.info> Message-ID: <4F5545B4.3070709@ruhr-uni-bochum.de> On 02/25/2012 01:53 AM, Hans-Christoph Steiner wrote: > > More Android porting fun! The good news is that I have working builds > for the whole thing, but working in a limited way. The build is also > repeatable and even automated. Once I get everything working, I'll also > add in the gnupg tests to the automated builds: > > https://build.safermobile.org/job/gnupg-for-android/ > > So now the problem at hand is more missing pthread symbols: > > libnpth.so: undefined reference to `pthread_rwlock_rdlock' > libnpth.so: undefined reference to `pthread_rwlock_timedwrlock' > libnpth.so: undefined reference to `pthread_rwlock_timedrdlock' > libnpth.so: undefined reference to `pthread_rwlock_wrlock' > libnpth.so: undefined reference to `pthread_rwlock_trywrlock' > libnpth.so: undefined reference to `pthread_rwlock_tryrdlock' > > The attached patch to npth gave me a libnpth.so that made gpg-agent > happy enough to run. dirmngr still doesn't run because libldap.so also > has the pthread_rwlock_* symbols, but I think I can solve that by using > ./configure --without-threads in openldap. I got the latest NDK and look what I found: $ for f in */arch-arm/usr/lib/libc.so; do grep -H pthread_rwlock_wrlock $f; done Binary file android-14/arch-arm/usr/lib/libc.so matches Binary file android-9/arch-arm/usr/lib/libc.so matches Seems that since v9 the functions are available. Which version are you using? Can you confirm? There is also a test for this in tests/build/pthread-rwlock-initializer Thanks, Marcus From hans at guardianproject.info Tue Mar 6 05:13:10 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Mon, 5 Mar 2012 23:13:10 -0500 Subject: Android does not have pthread_rwlock*, npth wants them In-Reply-To: <4F5545B4.3070709@ruhr-uni-bochum.de> References: <4F4830F7.9040601@guardianproject.info> <4F5545B4.3070709@ruhr-uni-bochum.de> Message-ID: On Mar 5, 2012, at 6:01 PM, Marcus Brinkmann wrote: > On 02/25/2012 01:53 AM, Hans-Christoph Steiner wrote: >> >> More Android porting fun! The good news is that I have working builds >> for the whole thing, but working in a limited way. The build is also >> repeatable and even automated. Once I get everything working, I'll also >> add in the gnupg tests to the automated builds: >> >> https://build.safermobile.org/job/gnupg-for-android/ >> >> So now the problem at hand is more missing pthread symbols: >> >> libnpth.so: undefined reference to `pthread_rwlock_rdlock' >> libnpth.so: undefined reference to `pthread_rwlock_timedwrlock' >> libnpth.so: undefined reference to `pthread_rwlock_timedrdlock' >> libnpth.so: undefined reference to `pthread_rwlock_wrlock' >> libnpth.so: undefined reference to `pthread_rwlock_trywrlock' >> libnpth.so: undefined reference to `pthread_rwlock_tryrdlock' >> >> The attached patch to npth gave me a libnpth.so that made gpg-agent >> happy enough to run. dirmngr still doesn't run because libldap.so also >> has the pthread_rwlock_* symbols, but I think I can solve that by using >> ./configure --without-threads in openldap. > > I got the latest NDK and look what I found: > > $ for f in */arch-arm/usr/lib/libc.so; do grep -H pthread_rwlock_wrlock $f; done > Binary file android-14/arch-arm/usr/lib/libc.so matches > Binary file android-9/arch-arm/usr/lib/libc.so matches > > Seems that since v9 the functions are available. Which version are you using? Can you confirm? > > There is also a test for this in tests/build/pthread-rwlock-initializer I thought I mentioned this in a follow-up email, my apologies if I did not. I'm currently using android-9/2.3 and its working fine as is, so seemingly using pthread_rwlock_*. Andrond 2.3 and above covers about 50% of the currently deployed Android devices, so it would be nice to be able to work without pthread_rwlock_* .hc ---------------------------------------------------------------------------- ?El pueblo unido jam?s ser? vencido! From hans at guardianproject.info Wed Mar 7 00:22:56 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 6 Mar 2012 18:22:56 -0500 Subject: pinentry for Android questions Message-ID: <9333EDAB-36A0-4061-8430-E27EC6C9D566@guardianproject.info> I'm trying to work out how best to implement pinentry for Android. Right now I'm thinking that it would be easiest to having a 'pinentry-android' which just launches the PassphraseEntry Activity (an core Android GUI class), then have the Java code reply to the UNIX socket using assuan. Another possibility is having the Java code write a temp file with the response. Any examples out there to draw from? Any suggestions along these lines? .hc ---------------------------------------------------------------------------- As we enjoy great advantages from inventions of others, we should be glad of an opportunity to serve others by any invention of ours; and this we should do freely and generously. - Benjamin Franklin From kwadronaut at autistici.org Wed Mar 7 12:14:36 2012 From: kwadronaut at autistici.org (kwadronaut) Date: Wed, 7 Mar 2012 11:14:36 +0000 (UTC) Subject: STEED - Usable end-to-end encryption References: <87ty774hf2.fsf__21985.2206683301$1318878302$gmane$org@vigenere.g10code.de> Message-ID: On Mon, 17 Oct 2011 20:11:29 +0200, Werner Koch wrote: > of the whole system. We prepared a short paper; if you are interested Some suggestions and questions, some are applicable to the paper while others might be more suited for a FAQ section on the website: * More pictures. * You're suggesting to 'to allow easy integration with the MUA it may be better to move the contact database into GnuPG proper.' I first read that as duplicating functionality of, for example, existing Directory Servers. Is that correct? If it isn't, maybe that paragraph could be clarified. * Address the concerns some have about DNSSEC (see Micah Andersons' mail from Fri 28 Oct 2011). Those concerns are mostly valid for TUFC if you don't rely on more traditional mechanisms like the WOT. * Address the size-concerns some (many?) have about publishing key material in DNS. I know about EDNS0 and TCP, but there's a myriad of firewalls and DNS-servers not being able to properly deal with that. IPv6 deployment is luckily (bit by bit) making more DNS-servers accessible to answers that are >512 bytes, but it's still a challenge. * in the conventions section you're listing GPGME as 'GnuPG Made Easy An application library used to access the feature of GnuPG.' I'd write features, in plural, don't be too modest ;-) * When suggesting DNS, IPGP records seem to make most sense to me, given the problems a lot of DNS-servers have with size. PKA and IPGP both require some other place to actually store the key. How do you picture solving that? Anyone has other suggestions or feedback on this? Maybe this list has more ideas on incentives for e-mail providers for this? kwadronaut From marcus.brinkmann at ruhr-uni-bochum.de Wed Mar 7 19:06:29 2012 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 7 Mar 2012 19:06:29 +0100 Subject: Android does not have pthread_rwlock*, npth wants them In-Reply-To: References: <4F4830F7.9040601@guardianproject.info> <4F5545B4.3070709@ruhr-uni-bochum.de> Message-ID: <4F57A3A5.1080204@ruhr-uni-bochum.de> On 03/06/2012 05:13 AM, Hans-Christoph Steiner wrote: > I thought I mentioned this in a follow-up email, my apologies if I did not. I'm currently using android-9/2.3 and its working fine as is, so seemingly using pthread_rwlock_*. Andrond 2.3 and above covers about 50% of the currently deployed Android devices, so it would be nice to be able to work without pthread_rwlock_* I might have missed it earlier. I have the Android NDK set up now. How far do you think we have to go back in the API level to cover all interesting devices? Thanks, Marcus From hans at guardianproject.info Wed Mar 7 19:22:27 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Wed, 7 Mar 2012 13:22:27 -0500 Subject: Android does not have pthread_rwlock*, npth wants them In-Reply-To: <4F57A3A5.1080204@ruhr-uni-bochum.de> References: <4F4830F7.9040601@guardianproject.info> <4F5545B4.3070709@ruhr-uni-bochum.de> <4F57A3A5.1080204@ruhr-uni-bochum.de> Message-ID: <1EA606D5-E21E-4CEB-9EA1-1C44A1799B27@guardianproject.info> On Mar 7, 2012, at 1:06 PM, Marcus Brinkmann wrote: > On 03/06/2012 05:13 AM, Hans-Christoph Steiner wrote: >> I thought I mentioned this in a follow-up email, my apologies if I did not. I'm currently using android-9/2.3 and its working fine as is, so seemingly using pthread_rwlock_*. Andrond 2.3 and above covers about 50% of the currently deployed Android devices, so it would be nice to be able to work without pthread_rwlock_* > > I might have missed it earlier. I have the Android NDK set up now. How far do you think we have to go back in the API level to cover all interesting devices? Depends who are you are specifically targeting. Here's the data from the Google Marketplace: http://developer.android.com/resources/dashboard/platform-versions.html Covering android-7/2.1 would give you 98.8% of the official Google phones that have Marketplace. Only Google branded phones have the Google Marketplace in them. For 3rd party ROMs, the Google Marketplace is an extra install. My guess is 3rd party ROM users are more up-to-date than Google users. There are also many very cheap Android devices that are not official Google devices, so they won't count in those statistics. Then there are devices like the Nook and the new Amazon Kindle which are widespread, based on Android, but not official Google devices. The old Nooks are 1.6. .hc ---------------------------------------------------------------------------- If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of everyone, and the receiver cannot dispossess himself of it. - Thomas Jefferson From marcus.brinkmann at ruhr-uni-bochum.de Fri Mar 9 16:30:55 2012 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 9 Mar 2012 16:30:55 +0100 Subject: npth finds pthread_mutex_timedlock() which android does not have In-Reply-To: <4F42A81F.7080004@guardianproject.info> References: <4F42A81F.7080004@guardianproject.info> Message-ID: <4F5A222F.3000003@ruhr-uni-bochum.de> On 02/20/2012 09:07 PM, Hans-Christoph Steiner wrote: > > Apparently, Android's NDK defines pthread_mutex_timedlock() in the > headers but then does not implement it. And it seems they aren't close > to implementing it: > http://code.google.com/p/android/issues/detail?id=2138 > > This is of course a really crappy situation since it means that you > can't do simple things like AC_CHECK_FUNCS([pthread_mutex_timedlock]) > because that actually finds the function. Actually, are you sure? I set up cross build environments for android-8, -9 and -14, and it seems to work as expected: android-8: checking for library containing pthread_create... none required checking for pthread_tryjoin_np... no checking for pthread_setname_np... no checking for pthread_getname_np... no checking for pthread_mutex_timedlock... no checking for pthread_rwlock_rdlock... no checking for pthread_rwlock_wrlock... no checking for pthread_rwlock_timedrdlock... no checking for pthread_rwlock_timedwrlock... no checking for pthread_rwlock_tryrdlock... no checking for pthread_rwlock_trywrlock... no android-9 and -14 (sorry, not the output, just the config.log): ac_cv_func_pthread_getname_np=no ac_cv_func_pthread_mutex_timedlock=no ac_cv_func_pthread_rwlock_rdlock=yes ac_cv_func_pthread_rwlock_timedrdlock=yes ac_cv_func_pthread_rwlock_timedwrlock=yes ac_cv_func_pthread_rwlock_tryrdlock=yes ac_cv_func_pthread_rwlock_trywrlock=yes ac_cv_func_pthread_rwlock_wrlock=yes ac_cv_func_pthread_setname_np=yes ac_cv_func_pthread_tryjoin_np=no And this makes sense, because AC_CHECK_FUNCS does not look at the header file, but if linking with the symbol works. The compile errors you get are due to the fact that these functions were used unconditionally in npth. I am going to work on replacement functions, but I want to make sure I am not missing something that makes AC_CHECK_FUNC fail for you. Thanks, Marcus From hans at guardianproject.info Fri Mar 9 16:41:31 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 9 Mar 2012 10:41:31 -0500 Subject: npth finds pthread_mutex_timedlock() which android does not have In-Reply-To: <4F5A222F.3000003@ruhr-uni-bochum.de> References: <4F42A81F.7080004@guardianproject.info> <4F5A222F.3000003@ruhr-uni-bochum.de> Message-ID: <069A6046-9E43-447E-8B3C-0895570098B0@guardianproject.info> On Mar 9, 2012, at 10:30 AM, Marcus Brinkmann wrote: > On 02/20/2012 09:07 PM, Hans-Christoph Steiner wrote: >> >> Apparently, Android's NDK defines pthread_mutex_timedlock() in the >> headers but then does not implement it. And it seems they aren't close >> to implementing it: >> http://code.google.com/p/android/issues/detail?id=2138 >> >> This is of course a really crappy situation since it means that you >> can't do simple things like AC_CHECK_FUNCS([pthread_mutex_timedlock]) >> because that actually finds the function. > > Actually, are you sure? I set up cross build environments for android-8, -9 and -14, and it seems to work as expected: > > android-8: > > checking for library containing pthread_create... none required > checking for pthread_tryjoin_np... no > checking for pthread_setname_np... no > checking for pthread_getname_np... no > checking for pthread_mutex_timedlock... no > checking for pthread_rwlock_rdlock... no > checking for pthread_rwlock_wrlock... no > checking for pthread_rwlock_timedrdlock... no > checking for pthread_rwlock_timedwrlock... no > checking for pthread_rwlock_tryrdlock... no > checking for pthread_rwlock_trywrlock... no > > android-9 and -14 (sorry, not the output, just the config.log): > > ac_cv_func_pthread_getname_np=no > ac_cv_func_pthread_mutex_timedlock=no > ac_cv_func_pthread_rwlock_rdlock=yes > ac_cv_func_pthread_rwlock_timedrdlock=yes > ac_cv_func_pthread_rwlock_timedwrlock=yes > ac_cv_func_pthread_rwlock_tryrdlock=yes > ac_cv_func_pthread_rwlock_trywrlock=yes > ac_cv_func_pthread_rwlock_wrlock=yes > ac_cv_func_pthread_setname_np=yes > ac_cv_func_pthread_tryjoin_np=no > > And this makes sense, because AC_CHECK_FUNCS does not look at the header file, but if linking with the symbol works. > > The compile errors you get are due to the fact that these functions were used unconditionally in npth. > > I am going to work on replacement functions, but I want to make sure I am not missing something that makes AC_CHECK_FUNC fail for you. I didn't look too deep into it, I just built it and ran it, and it complained about not finding pthread_rwlock_*. It sounds like you found the actual cause. .hc From marcus.brinkmann at ruhr-uni-bochum.de Fri Mar 9 16:50:48 2012 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 9 Mar 2012 16:50:48 +0100 Subject: pinentry for Android questions In-Reply-To: <9333EDAB-36A0-4061-8430-E27EC6C9D566@guardianproject.info> References: <9333EDAB-36A0-4061-8430-E27EC6C9D566@guardianproject.info> Message-ID: <4F5A26D8.9000309@ruhr-uni-bochum.de> On 03/07/2012 12:22 AM, Hans-Christoph Steiner wrote: > > I'm trying to work out how best to implement pinentry for Android. Right now I'm thinking that it would be easiest to having a 'pinentry-android' which just launches the PassphraseEntry Activity (an core Android GUI class), then have the Java code reply to the UNIX socket using assuan. That sounds about right, but I couldn't find documentation on PassphraseEntry to confirm that it supports the features that pinentry should support. There is a bunch of stuff going on there (description, quality bar, error text, prompt, button texts). Alternatively, the pinentry activity could just implement its own interface, as it only requires a couple of widgets. > Another possibility is having the Java code write a temp file with the response. Not quite as good, and not only because you commit the passphrase to storage. You don't really want to mug around in gpg-agent to avoid calling pinentry through libassuan. There is a bunch of stuff going on there, including gpg-agent reporting back on the quality of the passphrase incrementally as it is entered. > Any examples out there to draw from? Any suggestions along these lines? If you look at the pinentry source code, it's quite modular, and you only need to implement a single function (that serves several purposes though as it configures the widgets of the passphrase entry dialog window via a structure). There are some subtleties in how the interface is expected to behave, but nothing too bad. To keep the build simple, you don't have to integrate the android pinentry into the existing pinentry autoconf build, you can just make a standalone package. For this, copy pinentry/pinentry/pinentry.{h,c} and use the gtk+-2 implementation as a reference (ignore curses, the old gtk pinentry and the qt pinentries). You might want to (or have to) ignore secmem, it's used to disable swap space for passwords. Thanks, Marcus From komh78 at gmail.com Fri Mar 9 14:51:09 2012 From: komh78 at gmail.com (KO Myung-Hun) Date: Fri, 9 Mar 2012 22:51:09 +0900 Subject: [PATCH libgpg-error] Add OS/2 supports Message-ID: <1331301069-42800-1-git-send-email-komh@chollian.net> --- configure.ac | 8 ++++++++ src/Makefile.am | 8 ++++++-- 2 files changed, 14 insertions(+), 2 deletions(-) diff --git a/configure.ac b/configure.ac index ee42f9e..bd0c351 100644 --- a/configure.ac +++ b/configure.ac @@ -89,6 +89,7 @@ AC_ARG_VAR(CC_FOR_BUILD,[build system C compiler]) have_w32_system=no have_w64_system=no have_w32ce_system=no +have_os2_system=no case "${host}" in x86_64-*mingw32*) have_w32_system=yes @@ -101,6 +102,9 @@ case "${host}" in *-mingw32*) have_w32_system=yes ;; + *-os2*) + have_os2_system=yes + ;; *) ;; esac @@ -179,6 +183,10 @@ AM_CONDITIONAL(HAVE_W32_SYSTEM, test "$have_w32_system" = yes) AM_CONDITIONAL(HAVE_W64_SYSTEM, test "$have_w64_system" = yes) AM_CONDITIONAL(HAVE_W32CE_SYSTEM, test "$have_w32ce_system" = yes) +if test "$have_os2_system" = yes; then + AC_DEFINE(HAVE_OS2_SYSTEM,1,[Defined if we run on an OS/2 API based system]) +fi +AM_CONDITIONAL(HAVE_OS2_SYSTEM, test "$have_os2_system" = yes) AC_ARG_ENABLE(languages, [ --disable-languages do not build support for other languages than C]) diff --git a/src/Makefile.am b/src/Makefile.am index 518a4c0..5a1b49d 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -84,7 +84,11 @@ intllibs = else arch_sources = gpg_error_res = +if HAVE_OS2_SYSTEM +no_undefined = -no-undefined +else no_undefined = +endif export_symbols = install-def-file: uninstall-def-file: @@ -167,7 +171,7 @@ gpg-error.def: Makefile gpg-error.def.in # It is correct to use $(CC_FOR_BUILD) here. We want to run the # program at build time. -mkerrcodes: mkerrcodes.c mkerrcodes.h Makefile +mkerrcodes$(EXEEXT): mkerrcodes.c mkerrcodes.h Makefile $(CC_FOR_BUILD) -I. -I$(srcdir) -o $@ $(srcdir)/mkerrcodes.c if HAVE_W32CE_SYSTEM @@ -177,7 +181,7 @@ mkw32errmap: mkw32errmap.c mkw32errmap.tab.h Makefile $(CC_FOR_BUILD) -I. -I$(srcdir) -o $@ $(srcdir)/mkw32errmap.c endif -code-from-errno.h: mkerrcodes Makefile +code-from-errno.h: mkerrcodes$(EXEEXT) Makefile ./mkerrcodes | $(AWK) -f $(srcdir)/mkerrcodes2.awk >$@ errnos-sym.h: Makefile mkstrtable.awk errnos.in -- 1.7.3.2 From hans at guardianproject.info Fri Mar 9 18:37:15 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 9 Mar 2012 12:37:15 -0500 Subject: pinentry for Android questions In-Reply-To: <4F5A26D8.9000309@ruhr-uni-bochum.de> References: <9333EDAB-36A0-4061-8430-E27EC6C9D566@guardianproject.info> <4F5A26D8.9000309@ruhr-uni-bochum.de> Message-ID: <1E4A9464-47B4-4D8C-BDC4-62A210F83F95@guardianproject.info> On Mar 9, 2012, at 10:50 AM, Marcus Brinkmann wrote: > On 03/07/2012 12:22 AM, Hans-Christoph Steiner wrote: >> >> I'm trying to work out how best to implement pinentry for Android. Right now I'm thinking that it would be easiest to having a 'pinentry-android' which just launches the PassphraseEntry Activity (an core Android GUI class), then have the Java code reply to the UNIX socket using assuan. > > That sounds about right, but I couldn't find documentation on PassphraseEntry to confirm that it supports the features that pinentry should support. There is a bunch of stuff going on there (description, quality bar, error text, prompt, button texts). > > Alternatively, the pinentry activity could just implement its own interface, as it only requires a couple of widgets. Sorry, I meant Activity is a core Android GUI class, and PassphraseEntry is the class that we are writing. >> Another possibility is having the Java code write a temp file with the response. > > Not quite as good, and not only because you commit the passphrase to storage. You don't really want to mug around in gpg-agent to avoid calling pinentry through libassuan. There is a bunch of stuff going on there, including gpg-agent reporting back on the quality of the passphrase incrementally as it is entered. Yeah, duh, I realized this after sending... >> Any examples out there to draw from? Any suggestions along these lines? > > If you look at the pinentry source code, it's quite modular, and you only need to implement a single function (that serves several purposes though as it configures the widgets of the passphrase entry dialog window via a structure). > > There are some subtleties in how the interface is expected to behave, but nothing too bad. > > To keep the build simple, you don't have to integrate the android pinentry into the existing pinentry autoconf build, you can just make a standalone package. For this, copy pinentry/pinentry/pinentry.{h,c} and use the gtk+-2 implementation as a reference (ignore curses, the old gtk pinentry and the qt pinentries). > > You might want to (or have to) ignore secmem, it's used to disable swap space for passwords. I've been looking through the examples, those are hard to generalize from for this use case since they are all pure C and can all be linked together into a single program. What I would love to see is an example transcript of the assuan dialog between a pinentry program and gpg-agent, since I think I'll have to implement the whole pinentry lib in Java. Or perhaps I could wrap the pinentry C code in JNI for Java. .hc From marcus.brinkmann at ruhr-uni-bochum.de Fri Mar 9 19:12:34 2012 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 9 Mar 2012 19:12:34 +0100 Subject: pinentry for Android questions In-Reply-To: <1E4A9464-47B4-4D8C-BDC4-62A210F83F95@guardianproject.info> References: <9333EDAB-36A0-4061-8430-E27EC6C9D566@guardianproject.info> <4F5A26D8.9000309@ruhr-uni-bochum.de> <1E4A9464-47B4-4D8C-BDC4-62A210F83F95@guardianproject.info> Message-ID: <4F5A4812.3090603@ruhr-uni-bochum.de> On 03/09/2012 06:37 PM, Hans-Christoph Steiner wrote: > > I've been looking through the examples, those are hard to generalize from for this use case since they are all pure C and can all be linked together into a single program. What I would love to see is an example transcript of the assuan dialog between a pinentry program and gpg-agent, since I think I'll have to implement the whole pinentry lib in Java. Or perhaps I could wrap the pinentry C code in JNI for Java. > It's a lot easier to make pinentry.c/pinentry.h in a library and wrap that than to wrap libassuan or reimplement libassuan in Java. gpg-agent can be configured to log its assuan communication with pinentry. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Fri Mar 9 19:14:50 2012 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 9 Mar 2012 19:14:50 +0100 Subject: npth finds pthread_mutex_timedlock() which android does not have In-Reply-To: <4F42A81F.7080004@guardianproject.info> References: <4F42A81F.7080004@guardianproject.info> Message-ID: <4F5A489A.4050003@ruhr-uni-bochum.de> On 02/20/2012 09:07 PM, Hans-Christoph Steiner wrote: > Apparently, Android's NDK defines pthread_mutex_timedlock() in the > headers but then does not implement it. And it seems they aren't close > to implementing it: > http://code.google.com/p/android/issues/detail?id=2138 Hi, together with the previous changes, the latest version cbb52bd5ada02bbd914869f4540221831358d077 should resolve all rwlock issues on all android platforms up to 14. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Fri Mar 9 19:23:34 2012 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 9 Mar 2012 19:23:34 +0100 Subject: gpgme android build fails looking for /usr/local/lib/libgpg-error.la In-Reply-To: <4B24F294-2227-45EC-A380-94432741DE07@guardianproject.info> References: <4B24F294-2227-45EC-A380-94432741DE07@guardianproject.info> Message-ID: <4F5A4AA6.5040403@ruhr-uni-bochum.de> On 03/01/2012 02:29 AM, Hans-Christoph Steiner wrote: > > So gpgme is building fine on Android using the attached patch, it just doesn't finish linking to libgpg-error because the build system is convinced that its in /usr/local/lib, where it is definitely not. I tried to trace it a bit, but no luck yet. Any ideas where this is being set? > > To see how I'm building gpgme, check out the gpgme-build target in this Makefile, that will show the ./configure flags, etc. > https://github.com/guardianproject/gnupg-for-android/blob/master/external/Makefile It seems the libgpg-error configure is missing the --prefix=$(prefix) on the configure command line. That is necessary to set the path in gpg-error-config which is queried by gpgme's configure to locate gpg-error. I made a pull request on github (first time for me): https://github.com/guardianproject/gnupg-for-android/pull/2 Thanks, Marcus From hans at guardianproject.info Fri Mar 9 20:04:56 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 9 Mar 2012 14:04:56 -0500 Subject: gpgme android build fails looking for /usr/local/lib/libgpg-error.la In-Reply-To: <4F5A4AA6.5040403@ruhr-uni-bochum.de> References: <4B24F294-2227-45EC-A380-94432741DE07@guardianproject.info> <4F5A4AA6.5040403@ruhr-uni-bochum.de> Message-ID: <47BBC09B-8F76-4D41-B23E-0A9F4C149831@guardianproject.info> On Mar 9, 2012, at 1:23 PM, Marcus Brinkmann wrote: > On 03/01/2012 02:29 AM, Hans-Christoph Steiner wrote: >> >> So gpgme is building fine on Android using the attached patch, it just doesn't finish linking to libgpg-error because the build system is convinced that its in /usr/local/lib, where it is definitely not. I tried to trace it a bit, but no luck yet. Any ideas where this is being set? >> >> To see how I'm building gpgme, check out the gpgme-build target in this Makefile, that will show the ./configure flags, etc. >> https://github.com/guardianproject/gnupg-for-android/blob/master/external/Makefile > > It seems the libgpg-error configure is missing the --prefix=$(prefix) on the configure command line. > > That is necessary to set the path in gpg-error-config which is queried by gpgme's configure to locate gpg-error. > > I made a pull request on github (first time for me): > > https://github.com/guardianproject/gnupg-for-android/pull/2 Awesome, thank you! I merged it and am running a whole new build now. .hc From hans at at.or.at Sat Mar 10 00:44:22 2012 From: hans at at.or.at (Hans-Christoph Steiner) Date: Fri, 9 Mar 2012 18:44:22 -0500 Subject: gpgme android build fails looking for /usr/local/lib/libgpg-error.la In-Reply-To: <47BBC09B-8F76-4D41-B23E-0A9F4C149831@guardianproject.info> References: <4B24F294-2227-45EC-A380-94432741DE07@guardianproject.info> <4F5A4AA6.5040403@ruhr-uni-bochum.de> <47BBC09B-8F76-4D41-B23E-0A9F4C149831@guardianproject.info> Message-ID: <901AE897-26A5-4680-A333-71D7DD2FF874@at.or.at> On Mar 9, 2012, at 2:04 PM, Hans-Christoph Steiner wrote: > > On Mar 9, 2012, at 1:23 PM, Marcus Brinkmann wrote: > >> On 03/01/2012 02:29 AM, Hans-Christoph Steiner wrote: >>> >>> So gpgme is building fine on Android using the attached patch, it just doesn't finish linking to libgpg-error because the build system is convinced that its in /usr/local/lib, where it is definitely not. I tried to trace it a bit, but no luck yet. Any ideas where this is being set? >>> >>> To see how I'm building gpgme, check out the gpgme-build target in this Makefile, that will show the ./configure flags, etc. >>> https://github.com/guardianproject/gnupg-for-android/blob/master/external/Makefile >> >> It seems the libgpg-error configure is missing the --prefix=$(prefix) on the configure command line. >> >> That is necessary to set the path in gpg-error-config which is queried by gpgme's configure to locate gpg-error. >> >> I made a pull request on github (first time for me): >> >> https://github.com/guardianproject/gnupg-for-android/pull/2 > > Awesome, thank you! I merged it and am running a whole new build now. Here's the next step: - could you update config.sub and config.guess to the latest version? That's required for Android support, i.e. the host arm-linux-androidabi, otherwise ./configure dies like this: checking host system type... Invalid configuration `arm-linux-androideabi': system `androideabi' not recognized configure: error: /bin/bash ./config.sub arm-linux-androideabi failed - I needed to apply the attached simple patch to get things building since Android does not have SYS_gettid but does define __linux. It seems to be something in _GNU_SOURCE, so __gnu_linux__ seems an appropriate test. - the *-config scripts don't seem to work when cross-compiling, since they use prefix= but they don't include DESTDIR, i.e. they assume that the libs are all installed into their final destination. Or am I missing something? I'm using ./configure --with-gpg-error-prefix=$(LOCAL) ($LOCAL is the full path, not just the prefix) but that doesn't seem to help because I get: /bin/sed: can't read /data/data/info.guardianproject.gpg/app_opt/lib/libgpg-error.la: No such file or directory libtool: link: `/data/data/info.guardianproject.gpg/app_opt/lib/libgpg-error.la' is not a valid libtool archive I've also tried using sed to replace the prefix= line in each *-config script to the full path, and it also gives a similar error. But I found that merely running "make -C gpgme" works... .hc -------------- next part -------------- A non-text attachment was scrubbed... Name: gpgme-android-fixes.patch Type: application/octet-stream Size: 304 bytes Desc: not available URL: -------------- next part -------------- ---------------------------------------------------------------------------- Access to computers should be unlimited and total. - the hacker ethic From hans at guardianproject.info Sat Mar 10 04:34:17 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 09 Mar 2012 22:34:17 -0500 Subject: npth finds pthread_mutex_timedlock() which android does not have In-Reply-To: <4F5A489A.4050003@ruhr-uni-bochum.de> References: <4F42A81F.7080004@guardianproject.info> <4F5A489A.4050003@ruhr-uni-bochum.de> Message-ID: <4F5ACBB9.7040008@guardianproject.info> On 03/09/2012 01:14 PM, Marcus Brinkmann wrote: > On 02/20/2012 09:07 PM, Hans-Christoph Steiner wrote: >> Apparently, Android's NDK defines pthread_mutex_timedlock() in the >> headers but then does not implement it. And it seems they aren't close >> to implementing it: >> http://code.google.com/p/android/issues/detail?id=2138 > > Hi, > > together with the previous changes, the latest version > > cbb52bd5ada02bbd914869f4540221831358d077 > > should resolve all rwlock issues on all android platforms up to 14. I just ran a build that includes the latest gnupg and npth from git, and it builds fine on android-7/2.1: https://build.safermobile.org/job/gnupg-for-android/48/ Unfortunately, they didn't include the regex functions in android-7, so this will only run on android-8/2.2. We'll have to include the regex C files in this project in order to support < android-8/2.2. I think with including regex, we should be able to get gnupg running on even older platforms, like 1.6 so you have have gnupg on your old B&N Nook. ;) .hc From hans at guardianproject.info Sat Mar 10 04:35:23 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 09 Mar 2012 22:35:23 -0500 Subject: pinentry for Android questions In-Reply-To: <4F5A4812.3090603@ruhr-uni-bochum.de> References: <9333EDAB-36A0-4061-8430-E27EC6C9D566@guardianproject.info> <4F5A26D8.9000309@ruhr-uni-bochum.de> <1E4A9464-47B4-4D8C-BDC4-62A210F83F95@guardianproject.info> <4F5A4812.3090603@ruhr-uni-bochum.de> Message-ID: <4F5ACBFB.1010102@guardianproject.info> On 03/09/2012 01:12 PM, Marcus Brinkmann wrote: > On 03/09/2012 06:37 PM, Hans-Christoph Steiner wrote: >> >> I've been looking through the examples, those are hard to generalize >> from for this use case since they are all pure C and can all be linked >> together into a single program. What I would love to see is an >> example transcript of the assuan dialog between a pinentry program and >> gpg-agent, since I think I'll have to implement the whole pinentry lib >> in Java. Or perhaps I could wrap the pinentry C code in JNI for Java. >> > > It's a lot easier to make pinentry.c/pinentry.h in a library and wrap > that than to wrap libassuan or reimplement libassuan in Java. > > gpg-agent can be configured to log its assuan communication with pinentry. I forgot to mention, we're going to be using gpgme in this. It looks like gpgme somehow handles the pinentry stuff with callbacks, or am I reading it wrong? If we are using gpgme, do we still need a custom pinentry? .hc From hans at guardianproject.info Sat Mar 10 04:52:48 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Fri, 09 Mar 2012 22:52:48 -0500 Subject: npth finds pthread_mutex_timedlock() which android does not have In-Reply-To: <4F5ACBB9.7040008@guardianproject.info> References: <4F42A81F.7080004@guardianproject.info> <4F5A489A.4050003@ruhr-uni-bochum.de> <4F5ACBB9.7040008@guardianproject.info> Message-ID: <4F5AD010.3030501@guardianproject.info> On 03/09/2012 10:34 PM, Hans-Christoph Steiner wrote: > > > On 03/09/2012 01:14 PM, Marcus Brinkmann wrote: >> On 02/20/2012 09:07 PM, Hans-Christoph Steiner wrote: >>> Apparently, Android's NDK defines pthread_mutex_timedlock() in the >>> headers but then does not implement it. And it seems they aren't close >>> to implementing it: >>> http://code.google.com/p/android/issues/detail?id=2138 >> >> Hi, >> >> together with the previous changes, the latest version >> >> cbb52bd5ada02bbd914869f4540221831358d077 >> >> should resolve all rwlock issues on all android platforms up to 14. > > I just ran a build that includes the latest gnupg and npth from git, and > it builds fine on android-7/2.1: > > https://build.safermobile.org/job/gnupg-for-android/48/ > > Unfortunately, they didn't include the regex functions in android-7, so > this will only run on android-8/2.2. We'll have to include the regex C > files in this project in order to support < android-8/2.2. > > I think with including regex, we should be able to get gnupg running on > even older platforms, like 1.6 so you have have gnupg on your old B&N > Nook. ;) Oops I spoke too soon: # gpg-agent link_image[1995]: failed to link gpg-agent CANNOT LINK EXECUTABLE # dirmngr link_image[1995]: failed to link dirmngr CANNOT LINK EXECUTABLE Unfortunately, the Android linker doesn't give you much info, but you can get more info using ld. I copied all of the android-2.2 .so files into /tmp and did this: $ arm-linux-androideabi-ld --rpath=/tmp libnpth.so arm-linux-androideabi-ld: warning: cannot find entry symbol _start; defaulting to 00008248 libnpth.so: undefined reference to `pthread_rwlock_rdlock' libnpth.so: undefined reference to `pthread_rwlock_timedwrlock' libnpth.so: undefined reference to `pthread_rwlock_timedrdlock' libnpth.so: undefined reference to `pthread_rwlock_wrlock' libnpth.so: undefined reference to `pthread_rwlock_trywrlock' libnpth.so: undefined reference to `pthread_rwlock_tryrdlock' .hc From marcus.brinkmann at ruhr-uni-bochum.de Sat Mar 10 14:56:55 2012 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 10 Mar 2012 14:56:55 +0100 Subject: pinentry for Android questions In-Reply-To: <4F5ACBFB.1010102@guardianproject.info> References: <9333EDAB-36A0-4061-8430-E27EC6C9D566@guardianproject.info> <4F5A26D8.9000309@ruhr-uni-bochum.de> <1E4A9464-47B4-4D8C-BDC4-62A210F83F95@guardianproject.info> <4F5A4812.3090603@ruhr-uni-bochum.de> <4F5ACBFB.1010102@guardianproject.info> Message-ID: <4F5B5DA7.8060608@ruhr-uni-bochum.de> On 03/10/2012 04:35 AM, Hans-Christoph Steiner wrote: > > > On 03/09/2012 01:12 PM, Marcus Brinkmann wrote: >> On 03/09/2012 06:37 PM, Hans-Christoph Steiner wrote: >>> >>> I've been looking through the examples, those are hard to generalize >>> from for this use case since they are all pure C and can all be linked >>> together into a single program. What I would love to see is an >>> example transcript of the assuan dialog between a pinentry program and >>> gpg-agent, since I think I'll have to implement the whole pinentry lib >>> in Java. Or perhaps I could wrap the pinentry C code in JNI for Java. >>> >> >> It's a lot easier to make pinentry.c/pinentry.h in a library and wrap >> that than to wrap libassuan or reimplement libassuan in Java. >> >> gpg-agent can be configured to log its assuan communication with pinentry. > > I forgot to mention, we're going to be using gpgme in this. It looks > like gpgme somehow handles the pinentry stuff with callbacks, or am I > reading it wrong? If we are using gpgme, do we still need a custom > pinentry? The callbacks are "old school" and not functional for gpg2 with gpg-agent. :) So a custom pinentry is indeed needed, and you don't need to set a gpgme passphrase callback (it would never be called). Thanks for the list of issues, btw, it's a big help as the mailing list threads were getting a tiny bit unwieldy. Thanks, Marcus From marcus.brinkmann at ruhr-uni-bochum.de Mon Mar 12 16:52:16 2012 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 12 Mar 2012 16:52:16 +0100 Subject: gpgme android build fails looking for /usr/local/lib/libgpg-error.la In-Reply-To: <901AE897-26A5-4680-A333-71D7DD2FF874@at.or.at> References: <4B24F294-2227-45EC-A380-94432741DE07@guardianproject.info> <4F5A4AA6.5040403@ruhr-uni-bochum.de> <47BBC09B-8F76-4D41-B23E-0A9F4C149831@guardianproject.info> <901AE897-26A5-4680-A333-71D7DD2FF874@at.or.at> Message-ID: <4F5E1BB0.8070002@ruhr-uni-bochum.de> On 03/10/2012 12:44 AM, Hans-Christoph Steiner wrote: > > On Mar 9, 2012, at 2:04 PM, Hans-Christoph Steiner wrote: > >> >> On Mar 9, 2012, at 1:23 PM, Marcus Brinkmann wrote: >> >>> On 03/01/2012 02:29 AM, Hans-Christoph Steiner wrote: >>>> >>>> So gpgme is building fine on Android using the attached patch, it just doesn't finish linking to libgpg-error because the build system is convinced that its in /usr/local/lib, where it is definitely not. I tried to trace it a bit, but no luck yet. Any ideas where this is being set? >>>> >>>> To see how I'm building gpgme, check out the gpgme-build target in this Makefile, that will show the ./configure flags, etc. >>>> https://github.com/guardianproject/gnupg-for-android/blob/master/external/Makefile >>> >>> It seems the libgpg-error configure is missing the --prefix=$(prefix) on the configure command line. >>> >>> That is necessary to set the path in gpg-error-config which is queried by gpgme's configure to locate gpg-error. >>> >>> I made a pull request on github (first time for me): >>> >>> https://github.com/guardianproject/gnupg-for-android/pull/2 >> >> Awesome, thank you! I merged it and am running a whole new build now. > > Here's the next step: > > - could you update config.sub and config.guess to the latest version? That's required for Android support, i.e. the host arm-linux-androidabi, otherwise ./configure dies like this: > > checking host system type... Invalid configuration `arm-linux-androideabi': > system `androideabi' not recognized > configure: error: /bin/bash ./config.sub arm-linux-androideabi failed Fixed in gpgme ced1ad01aed32d1e4c5000f3b901db018ef7bf1e > - I needed to apply the attached simple patch to get things building since Android does not have SYS_gettid but does define __linux. It seems to be something in _GNU_SOURCE, so __gnu_linux__ seems an appropriate test. Or we just use __NR_gettid, which should work everywhere. Fixed in gpgme ff0a640a18e7b7457e6c2edfdc8307bf44628b60 > - the *-config scripts don't seem to work when cross-compiling, since they use prefix= but they don't include DESTDIR, i.e. they assume that the libs are all installed into their final destination. Or am I missing something? I'm using ./configure --with-gpg-error-prefix=$(LOCAL) ($LOCAL is the full path, not just the prefix) but that doesn't seem to help because I get: > > /bin/sed: can't read /data/data/info.guardianproject.gpg/app_opt/lib/libgpg-error.la: No such file or directory > libtool: link: `/data/data/info.guardianproject.gpg/app_opt/lib/libgpg-error.la' is not a valid libtool archive > > I've also tried using sed to replace the prefix= line in each *-config script to the full path, and it also gives a similar error. But I found that merely running "make -C gpgme" works... The way this is supposed to work is this: At configure time, --prefix= should be used with the actual path where the files will be found at the time you compile the next package. make DESTDIR is for installing into a staging area for packaging. The files will not be usable until they are relocated to the actual prefix. For a cross-build, things are confused a bit, of course, as you want to access the files in two locations, one path for the build system and one for the host. Oh well. For Windows builds, we prefer the cross environment and do the runtime lookup dynamically in cooperation with the installer. For non-Windows systems, the other way around may be more convenient. But then, you might have to do some work anyway to make sure files are found in the android filesystem, which probably is different from a normal Unix install. So I'd say try the approach to set the cross build locations with configure --prefix option, which is the least amount of hassle at build time, and then patch things up for the android host install later, by using configure options such as gpgme's --with-gpg or if necessary, adjusting the code that locates various bits of the system in gpgme and gpg (gpg-conf in particular). It depends on the packaging and how the android filesystem works. I might have a look at your build scripts and suggest something more specific, but maybe you have already thought about how the android packaging etc will work and can share some thoughts on that? Thanks, Marcus From hans at at.or.at Mon Mar 12 17:18:48 2012 From: hans at at.or.at (Hans-Christoph Steiner) Date: Mon, 12 Mar 2012 12:18:48 -0400 Subject: gpgme android build fails looking for /usr/local/lib/libgpg-error.la In-Reply-To: <4F5E1BB0.8070002@ruhr-uni-bochum.de> References: <4B24F294-2227-45EC-A380-94432741DE07@guardianproject.info> <4F5A4AA6.5040403@ruhr-uni-bochum.de> <47BBC09B-8F76-4D41-B23E-0A9F4C149831@guardianproject.info> <901AE897-26A5-4680-A333-71D7DD2FF874@at.or.at> <4F5E1BB0.8070002@ruhr-uni-bochum.de> Message-ID: On Mar 12, 2012, at 11:52 AM, Marcus Brinkmann wrote: > On 03/10/2012 12:44 AM, Hans-Christoph Steiner wrote: >> >> On Mar 9, 2012, at 2:04 PM, Hans-Christoph Steiner wrote: >> >>> >>> On Mar 9, 2012, at 1:23 PM, Marcus Brinkmann wrote: >>> >>>> On 03/01/2012 02:29 AM, Hans-Christoph Steiner wrote: >>>>> >>>>> So gpgme is building fine on Android using the attached patch, it just doesn't finish linking to libgpg-error because the build system is convinced that its in /usr/local/lib, where it is definitely not. I tried to trace it a bit, but no luck yet. Any ideas where this is being set? >>>>> >>>>> To see how I'm building gpgme, check out the gpgme-build target in this Makefile, that will show the ./configure flags, etc. >>>>> https://github.com/guardianproject/gnupg-for-android/blob/master/external/Makefile >>>> >>>> It seems the libgpg-error configure is missing the --prefix=$(prefix) on the configure command line. >>>> >>>> That is necessary to set the path in gpg-error-config which is queried by gpgme's configure to locate gpg-error. >>>> >>>> I made a pull request on github (first time for me): >>>> >>>> https://github.com/guardianproject/gnupg-for-android/pull/2 >>> >>> Awesome, thank you! I merged it and am running a whole new build now. >> >> Here's the next step: >> >> - could you update config.sub and config.guess to the latest version? That's required for Android support, i.e. the host arm-linux-androidabi, otherwise ./configure dies like this: >> >> checking host system type... Invalid configuration `arm-linux-androideabi': >> system `androideabi' not recognized >> configure: error: /bin/bash ./config.sub arm-linux-androideabi failed > > Fixed in gpgme ced1ad01aed32d1e4c5000f3b901db018ef7bf1e > >> - I needed to apply the attached simple patch to get things building since Android does not have SYS_gettid but does define __linux. It seems to be something in _GNU_SOURCE, so __gnu_linux__ seems an appropriate test. > > Or we just use __NR_gettid, which should work everywhere. > Fixed in gpgme ff0a640a18e7b7457e6c2edfdc8307bf44628b60 > >> - the *-config scripts don't seem to work when cross-compiling, since they use prefix= but they don't include DESTDIR, i.e. they assume that the libs are all installed into their final destination. Or am I missing something? I'm using ./configure --with-gpg-error-prefix=$(LOCAL) ($LOCAL is the full path, not just the prefix) but that doesn't seem to help because I get: >> >> /bin/sed: can't read /data/data/info.guardianproject.gpg/app_opt/lib/libgpg-error.la: No such file or directory >> libtool: link: `/data/data/info.guardianproject.gpg/app_opt/lib/libgpg-error.la' is not a valid libtool archive >> >> I've also tried using sed to replace the prefix= line in each *-config script to the full path, and it also gives a similar error. But I found that merely running "make -C gpgme" works... > > The way this is supposed to work is this: > > At configure time, --prefix= should be used with the actual path where the files will be found at the time you compile the next package. > > make DESTDIR is for installing into a staging area for packaging. The files will not be usable until they are relocated to the actual prefix. > > For a cross-build, things are confused a bit, of course, as you want to access the files in two locations, one path for the build system and one for the host. Oh well. For Windows builds, we prefer the cross environment and do the runtime lookup dynamically in cooperation with the installer. For non-Windows systems, the other way around may be more convenient. But then, you might have to do some work anyway to make sure files are found in the android filesystem, which probably is different from a normal Unix install. > > So I'd say try the approach to set the cross build locations with configure --prefix option, which is the least amount of hassle at build time, and then patch things up for the android host install later, by using configure options such as gpgme's --with-gpg or if necessary, adjusting the code that locates various bits of the system in gpgme and gpg (gpg-conf in particular). It depends on the packaging and how the android filesystem works. > > I might have a look at your build scripts and suggest something more specific, but maybe you have already thought about how the android packaging etc will work and can share some thoughts on that? Android's linker doesn't use rpath at all, so I think this is going to look more like the Windows setup you describe. The libraries are all installed on the phone to /data/data/info.guardianproject.gpg/app_opt/lib and that path is added to LD_LIBRARY_PATH in the environment where gpg2, gpg-agent, and dirmngr are run. So I guess I should change all the --prefix settings to be the cross-build install location, then use the --with-gpg, etc. options to set where the executables will be found on the phone. .hc ---------------------------------------------------------------------------- "[T]he greatest purveyor of violence in the world today [is] my own government." - Martin Luther King, Jr. From marcus.brinkmann at ruhr-uni-bochum.de Tue Mar 13 17:40:41 2012 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 13 Mar 2012 17:40:41 +0100 Subject: npth finds pthread_mutex_timedlock() which android does not have In-Reply-To: <4F5AD010.3030501@guardianproject.info> References: <4F42A81F.7080004@guardianproject.info> <4F5A489A.4050003@ruhr-uni-bochum.de> <4F5ACBB9.7040008@guardianproject.info> <4F5AD010.3030501@guardianproject.info> Message-ID: <4F5F7889.4050305@ruhr-uni-bochum.de> On 03/10/2012 04:52 AM, Hans-Christoph Steiner wrote: > Unfortunately, the Android linker doesn't give you much info, but you > can get more info using ld. I copied all of the android-2.2 .so files > into /tmp and did this: > > $ arm-linux-androideabi-ld --rpath=/tmp libnpth.so > arm-linux-androideabi-ld: warning: cannot find entry symbol _start; > defaulting to 00008248 > libnpth.so: undefined reference to `pthread_rwlock_rdlock' > libnpth.so: undefined reference to `pthread_rwlock_timedwrlock' > libnpth.so: undefined reference to `pthread_rwlock_timedrdlock' > libnpth.so: undefined reference to `pthread_rwlock_wrlock' > libnpth.so: undefined reference to `pthread_rwlock_trywrlock' > libnpth.so: undefined reference to `pthread_rwlock_tryrdlock' Did you build npth against API level < 9? You can't use the API level >= 9 builds of npth on earlier androids, because for those I enable the rwlock usage. If there is a general expectation in the Android community that you can install builds against later API levels on earlier devices, we may change that. Is that the case? I tried building gnupg-for-android in the following way, and did not see any dangling rwlock related references in libnpth.so: $ make -C external NDK_BASE=/.../android-ndk-r7b NDK_PLATFORM_LEVEL=8 gnupg-install $ arm-linux-androideabi-objdump --dynamic-syms libnpth.so.0.0.0 |grep '*UND*' | grep pthread_ 00000000 DF *UND* 00000000 pthread_create 00000000 DF *UND* 00000000 pthread_exit 00000000 DF *UND* 00000000 pthread_sigmask 00000000 DF *UND* 00000000 pthread_self 00000000 DF *UND* 00000000 pthread_mutex_lock 00000000 DF *UND* 00000000 pthread_cond_wait 00000000 DF *UND* 00000000 pthread_mutex_trylock 00000000 DF *UND* 00000000 pthread_join 00000000 DF *UND* 00000000 pthread_cond_timedwait If you did build against 8 and it still has undefined references, something is not working right. Here is what is supposed to happen: In npth/src/npth.h, I check the API level of Android, if it is < 9, I define _NPTH_NO_RWLOCK and define all npth_rwlock functions and types to equivalent mutex types or dummies. Also, if _NPTH_NO_RWLOCK is defined, in src/npth.c, no functions using pthread_rwlock are defined. If this isn't working for you, maybe you can find out what's going wrong? Thanks, Marcus From hans at guardianproject.info Tue Mar 13 22:19:50 2012 From: hans at guardianproject.info (Hans-Christoph Steiner) Date: Tue, 13 Mar 2012 17:19:50 -0400 Subject: npth finds pthread_mutex_timedlock() which android does not have In-Reply-To: <4F5F7889.4050305@ruhr-uni-bochum.de> References: <4F42A81F.7080004@guardianproject.info> <4F5A489A.4050003@ruhr-uni-bochum.de> <4F5ACBB9.7040008@guardianproject.info> <4F5AD010.3030501@guardianproject.info> <4F5F7889.4050305@ruhr-uni-bochum.de> Message-ID: <4F5FB9F6.5090102@guardianproject.info> On 03/13/2012 12:40 PM, Marcus Brinkmann wrote: > On 03/10/2012 04:52 AM, Hans-Christoph Steiner wrote: >> Unfortunately, the Android linker doesn't give you much info, but you >> can get more info using ld. I copied all of the android-2.2 .so files >> into /tmp and did this: >> >> $ arm-linux-androideabi-ld --rpath=/tmp libnpth.so >> arm-linux-androideabi-ld: warning: cannot find entry symbol _start; >> defaulting to 00008248 >> libnpth.so: undefined reference to `pthread_rwlock_rdlock' >> libnpth.so: undefined reference to `pthread_rwlock_timedwrlock' >> libnpth.so: undefined reference to `pthread_rwlock_timedrdlock' >> libnpth.so: undefined reference to `pthread_rwlock_wrlock' >> libnpth.so: undefined reference to `pthread_rwlock_trywrlock' >> libnpth.so: undefined reference to `pthread_rwlock_tryrdlock' > > Did you build npth against API level < 9? You can't use the API level >>= 9 builds of npth on earlier androids, because for those I enable the > rwlock usage. If there is a general expectation in the Android > community that you can install builds against later API levels on > earlier devices, we may change that. Is that the case? > > I tried building gnupg-for-android in the following way, and did not see > any dangling rwlock related references in libnpth.so: > > $ make -C external NDK_BASE=/.../android-ndk-r7b NDK_PLATFORM_LEVEL=8 > gnupg-install > > $ arm-linux-androideabi-objdump --dynamic-syms libnpth.so.0.0.0 |grep > '*UND*' | grep pthread_ > 00000000 DF *UND* 00000000 pthread_create > 00000000 DF *UND* 00000000 pthread_exit > 00000000 DF *UND* 00000000 pthread_sigmask > 00000000 DF *UND* 00000000 pthread_self > 00000000 DF *UND* 00000000 pthread_mutex_lock > 00000000 DF *UND* 00000000 pthread_cond_wait > 00000000 DF *UND* 00000000 pthread_mutex_trylock > 00000000 DF *UND* 00000000 pthread_join > 00000000 DF *UND* 00000000 pthread_cond_timedwait > > If you did build against 8 and it still has undefined references, > something is not working right. Here is what is supposed to happen: > > In npth/src/npth.h, I check the API level of Android, if it is < 9, I > define _NPTH_NO_RWLOCK and define all npth_rwlock functions and types to > equivalent mutex types or dummies. > > Also, if _NPTH_NO_RWLOCK is defined, in src/npth.c, no functions using > pthread_rwlock are defined. > > If this isn't working for you, maybe you can find out what's going wrong? You are correct, I hadn't changed NDK_PLATFORM_VERSION in externals/Makefile. Sorry for the noise. There are now 2 places where the platform has to be set... ug... project.properties and externals/Makefile. And it seems the earlier NDK version is android-5 but Google doesn't provide the SDK version android-5 nor the NDK version android-7. So it'd have to be SDK=android-7 NDK=android-5 if we wanted to support earlier versions. https://build.safermobile.org/job/gnupg-for-android/49/ .hc From dkg at fifthhorseman.net Wed Mar 14 05:09:00 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 14 Mar 2012 00:09:00 -0400 Subject: 2.1.0beta3: make check fails on test 17 of common/t-timestuff when TZ=America/New_York Message-ID: <4F6019DC.4060701@fifthhorseman.net> Hi GnuPG folks-- I'm trying to build gnupg 2.1.0beta3 on an i386 debian unstable machine. "make check" fails on test 17 (the last test) of common/t-timestuff when TZ=America/New_York, but succeeds when TZ=UTC. I can work around this pretty trivially in my build/test process, but it seems weird to have the outcome of "make check" be TZ-dependent. I assume this isn't intentional, but i'm not sure how/where you'd like it fixed. I can provide more details of the build/test environment where i'm seeing this behavior if it would be useful. Regards, --dkg From dkg at fifthhorseman.net Wed Mar 14 06:50:48 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 14 Mar 2012 01:50:48 -0400 Subject: 2.1.0beta3: long hang in genkey1024.test (work around with --debug-quick-random doesn't seem to speed things up?) Message-ID: <4F6031B8.100@fifthhorseman.net> Hi GnuPG folks-- I'm still trying to build gnupg 2.1.0beta3 on a headless i386 debian unstable system. the tests seem to take a really long time; in particular, tests/openpgp/genkey1024.test takes ages. I suspect it's trying to pull random data from the kernel, and the headless machine just doesn't have the entropy to supply it. This could potentially be a problem on debian's buildd's which may themselves be low on entropy. I tried patching genkey1024.test to add --debug-quick-random as an argument to gpg, but that didn't speed up the test either. observing the test in action, it appears that gpg is blocked reading from file descriptor 3, which is a socket. (presumably to gpg-agent? i can't find the gpg-agent instance on the build system, but perhaps it's just getting late and i'm missing obvious things). As an interim workaround, i've installed haveged on my build machine to keep the kernel's entropy pool well-populated, but i don't think that's a viable plan for everyone. What would be the right way to ask the key generation tests to use "quick-random" sources? I don't think we need real-world entropy for these tests, do we? --dkg From dkg at fifthhorseman.net Wed Mar 14 07:16:17 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 14 Mar 2012 02:16:17 -0400 Subject: dirmngr repository? In-Reply-To: <87boyfz9f8.fsf@vigenere.g10code.de> References: <1306942827.2405.55.camel@raven.home.flameeyes.eu> <87boyfz9f8.fsf@vigenere.g10code.de> Message-ID: <871uovaery.fsf@pip.fifthhorseman.net> On Fri, 03 Jun 2011 09:00:27 +0200, Werner Koch wrote: > That's right. Dirmngr has been merged with GnuPG. The GnuPG master has > a Dirmngr directory which has the most up to date code. We will only > do security updates for the old Dirmngr. Does this mean that the dirmngr package found at [0] is obsolete or superceded by the material in git, or by the source found in 2.1.0beta3? Should the source package download link be marked as deprecated? or will that deprecation wait until 2.1.0 is released? 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. Thanks, --dkg [0] http://www.gnupg.org/download/index.en.html#dirmngr From dkg at fifthhorseman.net Wed Mar 14 07:55:09 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 14 Mar 2012 02:55:09 -0400 Subject: 2.1.0beta3 missing man pages? Message-ID: <4F6040CD.5050003@fifthhorseman.net> 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 From wk at gnupg.org Wed Mar 14 09:55:45 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 Mar 2012 09:55:45 +0100 Subject: dirmngr repository? In-Reply-To: <871uovaery.fsf@pip.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 14 Mar 2012 02:16:17 -0400") References: <1306942827.2405.55.camel@raven.home.flameeyes.eu> <87boyfz9f8.fsf@vigenere.g10code.de> <871uovaery.fsf@pip.fifthhorseman.net> Message-ID: <87ty1r5zou.fsf@vigenere.g10code.de> On Wed, 14 Mar 2012 07:16, dkg at fifthhorseman.net said: > Does this mean that the dirmngr package found at [0] is obsolete or > superceded by the material in git, or by the source found in 2.1.0beta3? No, [0] is the current stable version. > will that deprecation wait until 2.1.0 is released? More likely until 2.2 has been released. I expect that a migration to 2.1 will take quite some time on Unix platforms. On Windows we plan to integrated into 2.1 into Gpg4win this year. > 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. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Mar 14 10:14:56 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 Mar 2012 10:14:56 +0100 Subject: 2.1.0beta3: make check fails on test 17 of common/t-timestuff when TZ=America/New_York In-Reply-To: <4F6019DC.4060701@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 14 Mar 2012 00:09:00 -0400") References: <4F6019DC.4060701@fifthhorseman.net> Message-ID: <87haxr5ysv.fsf@vigenere.g10code.de> On Wed, 14 Mar 2012 05:09, dkg at fifthhorseman.net said: > "make check" fails on test 17 (the last test) of common/t-timestuff > when TZ=America/New_York, but succeeds when TZ=UTC. Interesting: /* The date below is about the last time mktime works in CET on Windows XP; this is a somewhat strange because 32 bit Unices will happily work along for another month until they reach the end of all ticks on 20380119T031408 (unless Uli takes compassion on us and changes time_t to a u64). */ { 2037, 12, 18, 23, 59, 59} The last bits of the Epoch will reach us earlier? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Mar 14 10:20:11 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 Mar 2012 10:20:11 +0100 Subject: 2.1.0beta3: long hang in genkey1024.test (work around with --debug-quick-random doesn't seem to speed things up?) In-Reply-To: <4F6031B8.100@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 14 Mar 2012 01:50:48 -0400") References: <4F6031B8.100@fifthhorseman.net> Message-ID: <87d38f5yk4.fsf@vigenere.g10code.de> On Wed, 14 Mar 2012 06:50, dkg at fifthhorseman.net said: > I tried patching genkey1024.test to add --debug-quick-random as an > argument to gpg, but that didn't speed up the test either. Key generation is done by gpg-agent thus this option has no real effect. > What would be the right way to ask the key generation tests to use > "quick-random" sources? I don't think we need real-world entropy for > these tests, do we? No, we don't. However, all entropy hacks included in GnuPG have the potential problem that they may accidentally be used in real life. A faked /dev/random device would be a better way to run tests. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Mar 14 10:27:04 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 Mar 2012 10:27:04 +0100 Subject: 2.1.0beta3 missing man pages? In-Reply-To: <4F6040CD.5050003@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 14 Mar 2012 02:55:09 -0400") References: <4F6040CD.5050003@fifthhorseman.net> Message-ID: <878vj35yar.fsf@vigenere.g10code.de> On Wed, 14 Mar 2012 07:55, dkg at fifthhorseman.net said: > gpg-check-pattern That is a helper process to gpg-agent. It is by default installed in libexec so that it is not accessible via PATH. I am not sure whether it is useful as a separate tool. If you think it, is we should have a man page. > kbxutil As of now it is only a debugging aid. > g13 Don't install it, it is currently not very useful. > gpgkey2ssh That one will be dropped. > There is also a manpage for gpg-zip.1, but the tool appears to be > named gpgtar. gpgtar is not complete yet. I need to investigate what to do about it. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From nicholas.cole at gmail.com Wed Mar 14 10:34:34 2012 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Wed, 14 Mar 2012 09:34:34 +0000 Subject: 2.1.0beta3 missing man pages? In-Reply-To: <878vj35yar.fsf@vigenere.g10code.de> References: <4F6040CD.5050003@fifthhorseman.net> <878vj35yar.fsf@vigenere.g10code.de> Message-ID: On Wed, Mar 14, 2012 at 9:27 AM, Werner Koch wrote: > gpgtar is not complete yet. ?I need to investigate what to do about it. Could we have a 'DETAILS' like file in 2.1 describing what all the various bits of the system do? Even as someone who has followed gpg development for a long time, I would appreciate some kind of guide to what all of the different parts of the system are responsible for now. Best wishes, Nicholas From marcus.brinkmann at ruhr-uni-bochum.de Wed Mar 14 13:34:44 2012 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 14 Mar 2012 13:34:44 +0100 Subject: dirmngr repository? In-Reply-To: <1306942827.2405.55.camel@raven.home.flameeyes.eu> References: <1306942827.2405.55.camel@raven.home.flameeyes.eu> Message-ID: <4F609064.2050208@ruhr-uni-bochum.de> On 06/01/2011 05:40 PM, Diego Elio Petten? wrote: > Hello all, > > I was tracking down an issue with dirmngr today (underlinking: it uses > functions from liblber but it doesn't link to it directly by default), By the way, this issue has been fixed for the version of dirmngr in gnupg recently by me: gnupg 76ff42ef8d1232dd36bf48c1020b0b9b2afb1c7d diff --git a/configure.ac b/configure.ac index 47c6d12..6aadaa2 100644 --- a/configure.ac +++ b/configure.ac @@ -1009,7 +1009,14 @@ AM_CONDITIONAL(USE_DNS_SRV, test x"$use_dns_srv" = xyes) # if test "$try_ks_ldap" = yes || test "$build_dirmngr" = "yes" ; then GNUPG_CHECK_LDAP($NETLIBS) + AC_CHECK_LIB(lber, ber_free, + [ LBER_LIBS="$LBER_LIBS -llber" + AC_DEFINE(HAVE_LBER,1, + [defined if liblber is available]) + have_lber=yes + ]) fi +AC_SUBST(LBER_LIBS) # # Check for curl. We fake the curl API if libcurl isn't installed. diff --git a/dirmngr/Makefile.am b/dirmngr/Makefile.am index c5f073e..7c43165 100644 --- a/dirmngr/Makefile.am +++ b/dirmngr/Makefile.am @@ -72,7 +72,8 @@ dirmngr_ldap_SOURCES = dirmngr_ldap.c $(ldap_url) dirmngr_ldap_CFLAGS = $(GPG_ERROR_CFLAGS) $(LIBGCRYPT_CFLAGS) dirmngr_ldap_LDFLAGS = dirmngr_ldap_LDADD = $(libcommon) no-libgcrypt.o ../gl/libgnu.a $(DNSLIBS) \ - $(GPG_ERROR_LIBS) $(LDAPLIBS) $(LIBINTL) $(LIBICONV) + $(GPG_ERROR_LIBS) $(LDAPLIBS) $(LBER_LIBS) $(LIBINTL) \ + $(LIBICONV) endif dirmngr_client_SOURCES = dirmngr-client.c From dkg at fifthhorseman.net Wed Mar 14 16:56:43 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 14 Mar 2012 11:56:43 -0400 Subject: dirmngr repository? In-Reply-To: <4F609064.2050208@ruhr-uni-bochum.de> References: <1306942827.2405.55.camel@raven.home.flameeyes.eu> <4F609064.2050208@ruhr-uni-bochum.de> Message-ID: <4F60BFBB.3040806@fifthhorseman.net> On 03/14/2012 08:34 AM, Marcus Brinkmann wrote: > On 06/01/2011 05:40 PM, Diego Elio Petten? wrote: >> Hello all, >> >> I was tracking down an issue with dirmngr today (underlinking: it uses >> functions from liblber but it doesn't link to it directly by default), > > By the way, this issue has been fixed for the version of dirmngr in > gnupg recently by me: > > gnupg 76ff42ef8d1232dd36bf48c1020b0b9b2afb1c7d Is this fix going to be applied to the stable version? --dkg From marcus.brinkmann at ruhr-uni-bochum.de Wed Mar 14 22:39:20 2012 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 14 Mar 2012 22:39:20 +0100 Subject: dirmngr repository? In-Reply-To: <4F60BFBB.3040806@fifthhorseman.net> References: <1306942827.2405.55.camel@raven.home.flameeyes.eu> <4F609064.2050208@ruhr-uni-bochum.de> <4F60BFBB.3040806@fifthhorseman.net> Message-ID: <4F611008.1010203@ruhr-uni-bochum.de> On 03/14/2012 04:56 PM, Daniel Kahn Gillmor wrote: > On 03/14/2012 08:34 AM, Marcus Brinkmann wrote: >> On 06/01/2011 05:40 PM, Diego Elio Petten? wrote: >>> Hello all, >>> >>> I was tracking down an issue with dirmngr today (underlinking: it uses >>> functions from liblber but it doesn't link to it directly by default), >> >> By the way, this issue has been fixed for the version of dirmngr in >> gnupg recently by me: >> >> gnupg 76ff42ef8d1232dd36bf48c1020b0b9b2afb1c7d > > Is this fix going to be applied to the stable version? I am not sure if there is going to be another release of the stand alone dirmngr. Thanks, Marcus From dkg at fifthhorseman.net Wed Mar 14 22:53:04 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 14 Mar 2012 17:53:04 -0400 Subject: 2.1.0beta3 missing man pages? In-Reply-To: <878vj35yar.fsf@vigenere.g10code.de> References: <4F6040CD.5050003@fifthhorseman.net> <878vj35yar.fsf@vigenere.g10code.de> Message-ID: <4F611340.3070604@fifthhorseman.net> On 03/14/2012 05:27 AM, Werner Koch wrote: > On Wed, 14 Mar 2012 07:55, dkg at fifthhorseman.net said: > >> gpg-check-pattern > > That is a helper process to gpg-agent. It is by default installed in > libexec so that it is not accessible via PATH. I am not sure whether it > is useful as a separate tool. If you think it, is we should have a man > page. FWIW, there appear to be man pages for some other GnuPG 2.1.0beta3 binaries that are shipped in libexec. (i'm saying that's good, not asking you to get rid of them!) Without some documentation about how to use it (e.g. what the format is expected for the pattern files) it's hard to say if it would be useful. Inferring from its help output, it sounds similar in domain to the cracklib suite. people find cracklib is useful; so i'd guess that this would be as well. >> kbxutil > > As of now it is only a debugging aid. > >> g13 > > Don't install it, it is currently not very useful. > >> gpgkey2ssh > > That one will be dropped. > >> There is also a manpage for gpg-zip.1, but the tool appears to be >> named gpgtar. > > gpgtar is not complete yet. I need to investigate what to do about it. Thanks for these explanations, that's very helpful. Regards, --dkg From dkg at fifthhorseman.net Wed Mar 14 23:45:17 2012 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 14 Mar 2012 18:45:17 -0400 Subject: 2.1.0beta3: make check fails on test 17 of common/t-timestuff when TZ=America/New_York In-Reply-To: <87haxr5ysv.fsf@vigenere.g10code.de> References: <4F6019DC.4060701@fifthhorseman.net> <87haxr5ysv.fsf@vigenere.g10code.de> Message-ID: <4F611F7D.1000502@fifthhorseman.net> On 03/14/2012 05:14 AM, Werner Koch wrote: > On Wed, 14 Mar 2012 05:09, dkg at fifthhorseman.net said: > >> "make check" fails on test 17 (the last test) of common/t-timestuff >> when TZ=America/New_York, but succeeds when TZ=UTC. > > Interesting: > > /* The date below is about the last time mktime works in CET on > Windows XP; this is a somewhat strange because 32 bit Unices > will happily work along for another month until they reach the > end of all ticks on 20380119T031408 (unless Uli takes > compassion on us and changes time_t to a u64). */ > { 2037, 12, 18, 23, 59, 59} > > The last bits of the Epoch will reach us earlier? unlike tm_mday, tm_mon is zero-indexed (January = 0), so you're asking for the 13th month of 2037, which is in fact Jan 2038, at the expiration of the unix epoch (what the wall clock says when the epoch ends depends on your TZ). I think the comment above is mistaken. And yes, when the epoch rolls over, your wall clock will show a later time than my wall clock (unless one of us moves before then). :) --dkg From wk at gnupg.org Thu Mar 15 10:37:48 2012 From: wk at gnupg.org (Werner Koch) Date: Thu, 15 Mar 2012 10:37:48 +0100 Subject: dirmngr repository? In-Reply-To: <4F611008.1010203@ruhr-uni-bochum.de> (Marcus Brinkmann's message of "14 Mar 2012 22:39:20 +0100") References: <1306942827.2405.55.camel@raven.home.flameeyes.eu> <4F609064.2050208@ruhr-uni-bochum.de> <4F60BFBB.3040806@fifthhorseman.net> <4F611008.1010203@ruhr-uni-bochum.de> Message-ID: <87mx7i432r.fsf@vigenere.g10code.de> On Wed, 14 Mar 2012 22:39, marcus.brinkmann at ruhr-uni-bochum.de said: > I am not sure if there is going to be another release of the stand > alone dirmngr. If Debian needs this we should consider a new release. Unless it would be sufficient to have a Debian only patch. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gnupg-devel at mlists.thewrittenword.com Thu Mar 15 18:41:57 2012 From: gnupg-devel at mlists.thewrittenword.com (Albert Chin) Date: Thu, 15 Mar 2012 12:41:57 -0500 Subject: gpg-agent and AIX Message-ID: <20120315174156.GD1837@thewrittenword.com> 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? -- albert chin (china at thewrittenword.com) From gnupg-devel at mlists.thewrittenword.com Thu Mar 15 21:46:27 2012 From: gnupg-devel at mlists.thewrittenword.com (Albert Chin) Date: Thu, 15 Mar 2012 15:46:27 -0500 Subject: gpg-agent and AIX In-Reply-To: <20120315174156.GD1837@thewrittenword.com> References: <20120315174156.GD1837@thewrittenword.com> Message-ID: <20120315204626.GG1837@thewrittenword.com> On Thu, Mar 15, 2012 at 12:41:57PM -0500, Albert Chin wrote: > 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? The patch below fixes the issue for us. Glib does something similar. -- albert chin (china at thewrittenword.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: gnupg.patch Type: text/x-diff Size: 434 bytes Desc: not available URL: From martin at gnutiken.se Fri Mar 16 17:31:26 2012 From: martin at gnutiken.se (Martin Stenberg) Date: Fri, 16 Mar 2012 17:31:26 +0100 Subject: secure memory for decryption buffer Message-ID: <20120316163126.GA17070@gnutiken.se> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From bjk at luxsci.net Fri Mar 16 23:00:05 2012 From: bjk at luxsci.net (Ben Kibbey) Date: Fri, 16 Mar 2012 18:00:05 -0400 Subject: secure memory for decryption buffer In-Reply-To: <20120316163126.GA17070@gnutiken.se> References: <20120316163126.GA17070@gnutiken.se> Message-ID: <201203162201.q2GM12h1002190@rs136.luxsci.com> On Fri, Mar 16, 2012 at 05:31:26PM +0100, Martin Stenberg wrote: > 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. I have a project that does the same by using libassuan and gpg-agent. Maybe you'd be interested in helping me with it? If so, the url is http://pwmd.sourceforge.net/. > 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? I use the custom memory allocators to create a linked list of pointers which are zero'd before being freed. -- Ben Kibbey [XMPP: bjk AT jabber DOT org] - [IRC: (bjk) FreeNode/OFTC] From robbat2 at gentoo.org Sat Mar 17 00:18:14 2012 From: robbat2 at gentoo.org (Robin H. Johnson) Date: Fri, 16 Mar 2012 23:18:14 +0000 Subject: secure memory for decryption buffer In-Reply-To: <20120316163126.GA17070@gnutiken.se> References: <20120316163126.GA17070@gnutiken.se> Message-ID: On Fri, Mar 16, 2012 at 05:31:26PM +0100, Martin Stenberg wrote: > 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. This sounds very similar to the Debian pwstore application. https://github.com/formorer/pwstore -- Robin Hugh Johnson Gentoo Linux: Developer, Trustee & Infrastructure Lead E-Mail : robbat2 at gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 From wk at gnupg.org Sun Mar 18 17:11:30 2012 From: wk at gnupg.org (Werner Koch) Date: Sun, 18 Mar 2012 17:11:30 +0100 Subject: secure memory for decryption buffer In-Reply-To: <20120316163126.GA17070@gnutiken.se> (Martin Stenberg's message of "Fri, 16 Mar 2012 17:31:26 +0100") References: <20120316163126.GA17070@gnutiken.se> Message-ID: <877gyh51ot.fsf@vigenere.g10code.de> On Fri, 16 Mar 2012 17:31, martin at gnutiken.se said: > 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. There is no need for it. GnuPG manages its passphrases using the gpg-agent daemon. GPGME does not need to care about passphrases. Well, there is an API for passphrases, but it is only used by old GnuPG versions; its use is not recommended. The use of mlock is not trivial and more or less impossible for a general purpose library like GPGME. Further, the protection this "secure memory" provides is very questionable these days. You are better off using an encrypted swap partition. Using an mlocked memory area for arbitrary sizes of data is not a good idea in any case. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From martin at gnutiken.se Sun Mar 18 17:28:48 2012 From: martin at gnutiken.se (Martin Stenberg) Date: Sun, 18 Mar 2012 17:28:48 +0100 Subject: secure memory for decryption buffer In-Reply-To: <201203162201.q2GM12h1002190@rs136.luxsci.com> References: <20120316163126.GA17070@gnutiken.se> <201203162201.q2GM12h1002190@rs136.luxsci.com> Message-ID: <20120318162848.GA6304@gnutiken.se> On Fri, Mar 16, 2012 at 06:00:05PM -0400, Ben Kibbey wrote: > I have a project that does the same by using libassuan and gpg-agent. > Maybe you'd be interested in helping me with it? If so, the url is > http://pwmd.sourceforge.net/. Thanks for the invite. I am however looking for a very small command line tool, something like https://github.com/AlexBio/Safely. Safely is pretty much exactly what I'm writing, minus jansson depenency and some extra feautres. I'm mostly doing this to improve my skills in C and play with encryption :) > I use the custom memory allocators to create a linked list of > pointers which are zero'd before being freed. I've been leaning towards walking that path but am now considering using mlockall instead. I don't know if this is a bad idea or not though. /Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From martin at gnutiken.se Sun Mar 18 17:33:07 2012 From: martin at gnutiken.se (Martin Stenberg) Date: Sun, 18 Mar 2012 17:33:07 +0100 Subject: secure memory for decryption buffer In-Reply-To: References: <20120316163126.GA17070@gnutiken.se> Message-ID: <20120318163307.GB6304@gnutiken.se> On Fri, Mar 16, 2012 at 11:18:14PM +0000, Robin H. Johnson wrote: > This sounds very similar to the Debian pwstore application. > https://github.com/formorer/pwstore It is indeed. It is also very similar to Safely (https://github.com/AlexBio/Safely), pwman (http://pwman.sourceforge.net/) and probably a hundred others :) I'm mostly doing this out of educationaly interests. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From martin at gnutiken.se Sun Mar 18 17:44:22 2012 From: martin at gnutiken.se (Martin Stenberg) Date: Sun, 18 Mar 2012 17:44:22 +0100 Subject: secure memory for decryption buffer In-Reply-To: <877gyh51ot.fsf@vigenere.g10code.de> References: <20120316163126.GA17070@gnutiken.se> <877gyh51ot.fsf@vigenere.g10code.de> Message-ID: <20120318164421.GC6304@gnutiken.se> On Sun, Mar 18, 2012 at 05:11:30PM +0100, Werner Koch wrote: > There is no need for it. GnuPG manages its passphrases using the > gpg-agent daemon. GPGME does not need to care about passphrases. Well, > there is an API for passphrases, but it is only used by old GnuPG > versions; its use is not recommended. It is not the passphrases I'm concerned about in this case, but the content of the encrypted file (which in my case is a big list of passwords). > The use of mlock is not trivial and more or less impossible for a > general purpose library like GPGME. Further, the protection this > "secure memory" provides is very questionable these days. You are > better off using an encrypted swap partition. > > Using an mlocked memory area for arbitrary sizes of data is not a good > idea in any case. Could gpgme not have memory allocator callbacks though, like assuans assuan_malloc_hooks? But perhaps this is pointless if mlocks are a bad idea anyways. I'm very interested in knowing more about why keeping things in ram as a protection are a questionable defence these days. Could you please elaborate on this? Cheers! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: From beebe at math.utah.edu Sun Mar 18 19:29:57 2012 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Sun, 18 Mar 2012 12:29:57 -0600 (MDT) Subject: secure memory for decryption buffer Message-ID: Martin Stenberg asks on Sun, 18 Mar 2012 17:44:22 +0100 >> ... >> I'm very interested in knowing more about why keeping things in ram as >> a protection are a questionable defence these days. Could you please >> elaborate on this? >> ... Take a look at this article: J. Alex Halderman and eight others Lest we remember: cold-boot attacks on encryption keys Communications of the ACM 52(5) 91--98 May 2009 http://doi.acm.org/10.1145/1506409.1506429 ------------------------------------------------------------------------------- - 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 bisson at archlinux.org Mon Mar 19 07:20:14 2012 From: bisson at archlinux.org (Gaetan Bisson) Date: Mon, 19 Mar 2012 07:20:14 +0100 Subject: Stable GnuPG: 1.4.12 vs 2.0.18 Message-ID: <20120319062014.GA1062@aji.vesath.org> 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 -- Gaetan From wk at gnupg.org Mon Mar 19 08:38:52 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 19 Mar 2012 08:38:52 +0100 Subject: secure memory for decryption buffer In-Reply-To: <20120318164421.GC6304@gnutiken.se> (Martin Stenberg's message of "Sun, 18 Mar 2012 17:44:22 +0100") References: <20120316163126.GA17070@gnutiken.se> <877gyh51ot.fsf@vigenere.g10code.de> <20120318164421.GC6304@gnutiken.se> Message-ID: <871uop3ur7.fsf@vigenere.g10code.de> On Sun, 18 Mar 2012 17:44, martin at gnutiken.se said: > I'm very interested in knowing more about why keeping things in ram as a > protection are a questionable defence these days. Could you please > elaborate on this? The reason you use mlock is to make sure that sensitive data does not end up in the swap space. This is a valid concern and I implemented this whole secure memory stuff 15 years ago as a defense against this threat. However there is a much easier defense: Encrypt the swap space using a random key. There is no need for any kind of key management; the system just creates a one time key and holds this in non-pageable kernel memory. Swapping is mostly I/O bound thus there are enough free cycles to encrypt/decrypt the pages. Another problem is that mlock does not help against hibernation - eventually the content of the RAM will end up on the disk. Yet another one is that I don't buy the arguments that it is possible to protect a standard box against an attacker with physical access. There is a wide range of possible attacks, the simplest one being a key logger device. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Mon Mar 19 11:32:39 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 19 Mar 2012 11:32:39 +0100 Subject: Stable GnuPG: 1.4.12 vs 2.0.18 In-Reply-To: <20120319062014.GA1062@aji.vesath.org> (Gaetan Bisson's message of "Mon, 19 Mar 2012 07:20:14 +0100") References: <20120319062014.GA1062@aji.vesath.org> Message-ID: <87sjh43mpk.fsf@vigenere.g10code.de> On Mon, 19 Mar 2012 07:20, bisson at archlinux.org said: > 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? We maintain two stable branches: 1.4. and 2.0. If you ask which one you should use, the answer depends on the environment: 1. For unattended servers, 1.4 is is the easiest solution. In general you will only encrypt or verify signatures on such boxes. Thus there is no need for a passphrase. 2. For old Unix systems with 2.x build problems, you may resort to 1.4. 3. For all desktop systems, 2.0 is the suggested versions. New development is only done on 2.0. The standard installer for Windows uses 2.x. All new ports are even using 2.1. In case you really really don't want the Pinentry, 2.1 will eventually offer you a way to use the passphrase in the same as done in 1.4. If you build 2.0, I even suggest to use the configure option --enable-standard-socket which uses ~/.gnupg/S.gpg-agent as the default IPC socket. For home directories on remote file systems which don't support local sockets, it would be useful to document that the option "no-use-standard-socket" in the gpg-agent.conf file reverts it back to the old behaviour. We have a very good experience with an on-the-fly started gpg-agent under Windows and there is no reason not to use this also under Unix. 2.1 will make this the default anyway. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From g.esp at free.fr Mon Mar 19 12:41:29 2012 From: g.esp at free.fr (g.esp at free.fr) Date: Mon, 19 Mar 2012 12:41:29 +0100 (CET) Subject: Stable GnuPG: 1.4.12 vs 2.0.18 In-Reply-To: <87sjh43mpk.fsf@vigenere.g10code.de> Message-ID: <723650932.64158859.1332157289567.JavaMail.root@zimbra33-e6.priv.proxad.net> ----- Mail original ----- > De: "Werner Koch" > ?: "Gaetan Bisson" > Cc: gnupg-devel at gnupg.org > Envoy?: Lundi 19 Mars 2012 11:32:39 > Objet: Re: Stable GnuPG: 1.4.12 vs 2.0.18 > > On Mon, 19 Mar 2012 07:20, bisson at archlinux.org said: > > > 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? > > We maintain two stable branches: 1.4. and 2.0. If you ask which one > you should use, the answer depends on the environment: > On http://www.gnupg.org/download/release_notes.en.html should you not reword that part: 1.4.12 is the stable version of GnuPG. (2.0.18 is the unstable development version). Gilles From wk at gnupg.org Mon Mar 19 14:06:03 2012 From: wk at gnupg.org (Werner Koch) Date: Mon, 19 Mar 2012 14:06:03 +0100 Subject: Stable GnuPG: 1.4.12 vs 2.0.18 In-Reply-To: <723650932.64158859.1332157289567.JavaMail.root@zimbra33-e6.priv.proxad.net> (g. esp's message of "Mon, 19 Mar 2012 12:41:29 +0100 (CET)") References: <723650932.64158859.1332157289567.JavaMail.root@zimbra33-e6.priv.proxad.net> Message-ID: <87fwd43flw.fsf@vigenere.g10code.de> On Mon, 19 Mar 2012 12:41, g.esp at free.fr said: > On http://www.gnupg.org/download/release_notes.en.html > should you not reword that part: Yes, indeed. I have not looked at this file for ages. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Mar 20 22:06:06 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Mar 2012 22:06:06 +0100 Subject: bug tracker is down Message-ID: <87bonr0ypt.fsf@vigenere.g10code.de> Hi! Our bug tracker is currently down. I'll fix it tomorrow. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed Mar 21 17:42:39 2012 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 Mar 2012 17:42:39 +0100 Subject: [solved] Re: bug tracker is down In-Reply-To: <87bonr0ypt.fsf@vigenere.g10code.de> (Werner Koch's message of "Tue, 20 Mar 2012 22:06:06 +0100") References: <87bonr0ypt.fsf@vigenere.g10code.de> Message-ID: <87vclxzz0g.fsf@vigenere.g10code.de> On Tue, 20 Mar 2012 22:06, wk at gnupg.org said: > Our bug tracker is currently down. I'll fix it tomorrow. It is up again. Let me know if you have any problems. As usual with roundup, I had to tweak a bit of the configuration. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wking at drexel.edu Mon Mar 26 05:27:35 2012 From: wking at drexel.edu (W. Trevor King) Date: Sun, 25 Mar 2012 23:27:35 -0400 Subject: gpgme-agent (GPGME over Assuan) feedback request In-Reply-To: References: Message-ID: <20120326032735.GC1556@odin.tremily.us> Hi! I've been messing around with a Python wrappers around GnuPG every once and a while for a few years now, but nothing I've seen or done has felt particularly natural. I've just finished the initial stages of an approach that I haven't seen before: a cryptographic agent that you can communicate with via Assuan [1]. It's similar to gpg-agent, except instead of manging passphrases and keys, my agent signs, encrypts, and verifies data. Because it uses GPGME to do the cryptography, I'm calling it gpgme-agent. If you're in another language (such as Python), I think it's easier to communicate via sockets with a C-based agent than to use a wrapping mechanism to call the libraries directly. On the other hand, there may be some security issues with my approach that I'm overlooking. Anyhow, I'd appreciate some feedback on this approach. I'm posting to gnupg-devel rather than gnupg-users, because if people think this is a useful approach, I'd like to flesh it out and get it included in the standard set of GnuPG tools. If this is outside that scope, that's fine too, and I'll keep it simpler. Thanks, Trevor [1]: http://git.tremily.us/?p=gpgme-agent.git git://tremily.us/gpgme-agent.git -- 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 Mon Mar 26 15:48:40 2012 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 26 Mar 2012 15:48:40 +0200 Subject: gpgme-agent (GPGME over Assuan) feedback request In-Reply-To: <20120326032735.GC1556@odin.tremily.us> References: <20120326032735.GC1556@odin.tremily.us> Message-ID: <4F7073B8.2030800@ruhr-uni-bochum.de> On 03/26/2012 05:27 AM, W. Trevor King wrote: > Hi! > > I've been messing around with a Python wrappers around GnuPG every > once and a while for a few years now, but nothing I've seen or done > has felt particularly natural. I've just finished the initial stages > of an approach that I haven't seen before: a cryptographic agent that > you can communicate with via Assuan [1]. It's similar to gpg-agent, > except instead of manging passphrases and keys, my agent signs, > encrypts, and verifies data. Because it uses GPGME to do the > cryptography, I'm calling it gpgme-agent. Haven't looked at it in detail yet, but are you aware of gpgme/src/gpgme-tool.c ? It's used for testing only, so it doesn't have much polish, but it seems vaguely related to what you are doing :) Thanks, Marcus From wking at drexel.edu Mon Mar 26 17:00:09 2012 From: wking at drexel.edu (W. Trevor King) Date: Mon, 26 Mar 2012 11:00:09 -0400 Subject: gpgme-agent (GPGME over Assuan) feedback request In-Reply-To: <4F7073B8.2030800@ruhr-uni-bochum.de> References: <20120326032735.GC1556@odin.tremily.us> <4F7073B8.2030800@ruhr-uni-bochum.de> Message-ID: <20120326150009.GA4246@odin.tremily.us> On Mon, Mar 26, 2012 at 03:48:40PM +0200, Marcus Brinkmann wrote: > Haven't looked at it in detail yet, but are you aware of > gpgme/src/gpgme-tool.c ? It's used for testing only, so it doesn't have > much polish, but it seems vaguely related to what you are doing :) I was not aware of it ;). No need to look through my code anymore, I'm ditching it in favor of gpgme-tool. What can I do to help polish? It looks like there's currently no documentation? -- 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 Mon Mar 26 17:16:15 2012 From: marcus.brinkmann at ruhr-uni-bochum.de (Marcus Brinkmann) Date: 26 Mar 2012 17:16:15 +0200 Subject: gpgme-agent (GPGME over Assuan) feedback request In-Reply-To: <20120326150009.GA4246@odin.tremily.us> References: <20120326032735.GC1556@odin.tremily.us> <4F7073B8.2030800@ruhr-uni-bochum.de> <20120326150009.GA4246@odin.tremily.us> Message-ID: <4F70883F.1010002@ruhr-uni-bochum.de> On 03/26/2012 05:00 PM, W. Trevor King wrote: > On Mon, Mar 26, 2012 at 03:48:40PM +0200, Marcus Brinkmann wrote: >> Haven't looked at it in detail yet, but are you aware of >> gpgme/src/gpgme-tool.c ? It's used for testing only, so it doesn't have >> much polish, but it seems vaguely related to what you are doing :) > > I was not aware of it ;). No need to look through my code anymore, > I'm ditching it in favor of gpgme-tool. What can I do to help polish? > It looks like there's currently no documentation? > Documentation is badly needed for sure. I don't really remember any details about all the functions it provides, and what gaps there may be. Whatever prevents you from doing your thing, I'd say. Thanks, Marcus From wk at gnupg.org Tue Mar 27 11:20:14 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 27 Mar 2012 11:20:14 +0200 Subject: [Announce] GnuPG 2.0.19 released Message-ID: <871uoev1rl.fsf@vigenere.g10code.de> 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 . We suggest to send bug reports for a new release to this list in favor of filing a bug at . 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 -- 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 wking at drexel.edu Tue Mar 27 14:45:12 2012 From: wking at drexel.edu (W. Trevor King) Date: Tue, 27 Mar 2012 08:45:12 -0400 Subject: gpgme-tool documentation updates In-Reply-To: <4F70883F.1010002@ruhr-uni-bochum.de> References: <20120326032735.GC1556@odin.tremily.us> <4F7073B8.2030800@ruhr-uni-bochum.de> <20120326150009.GA4246@odin.tremily.us> <4F70883F.1010002@ruhr-uni-bochum.de> Message-ID: <20120327124508.GA29164@odin.tremily.us> On Mon, Mar 26, 2012 at 05:16:15PM +0200, Marcus Brinkmann wrote: > Documentation is badly needed for sure. I don't really remember any > details about all the functions it provides, and what gaps there may be. I've started moving through the docs trying to get a feel for gpgme-agent, and making corrections or additions as I see the need. How should I submit the changes? Should I mail patches to this thread (`git send-email ?`) or publish my git repository somewhere and email pull requests? -- 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 Tue Mar 27 17:53:38 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 27 Mar 2012 17:53:38 +0200 Subject: gpgme-tool documentation updates In-Reply-To: <20120327124508.GA29164@odin.tremily.us> (W. Trevor King's message of "Tue, 27 Mar 2012 08:45:12 -0400") References: <20120326032735.GC1556@odin.tremily.us> <4F7073B8.2030800@ruhr-uni-bochum.de> <20120326150009.GA4246@odin.tremily.us> <4F70883F.1010002@ruhr-uni-bochum.de> <20120327124508.GA29164@odin.tremily.us> Message-ID: <87mx72t4zh.fsf@vigenere.g10code.de> On Tue, 27 Mar 2012 14:45, wking at drexel.edu said: > How should I submit the changes? Should I mail patches to this thread > (`git send-email ?`) or publish my git repository somewhere and email Please send patches. That is easier for us to handle. If they are too long, please send them by private mail to Marcus. Note, that gpg-tool has an online help system. Most of the documentation can go there. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Mar 27 19:09:01 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 27 Mar 2012 19:09:01 +0200 Subject: 2.1.0beta3 missing man pages? In-Reply-To: <4F611340.3070604@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 14 Mar 2012 17:53:04 -0400") References: <4F6040CD.5050003@fifthhorseman.net> <878vj35yar.fsf@vigenere.g10code.de> <4F611340.3070604@fifthhorseman.net> Message-ID: <87bonit1hu.fsf@vigenere.g10code.de> On Wed, 14 Mar 2012 22:53, dkg at fifthhorseman.net said: > useful. Inferring from its help output, it sounds similar in domain to > the cracklib suite. people find cracklib is useful; so i'd guess that Right. It is a simple pattern matching tool which is called by gpg-agent to evaluate the quality of passphrases. The goal was to have a way to match passphrases against number plates of cars. I don't think that this is a useful thing to do, but a client asked for it because their security policy required it. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Mar 27 19:14:07 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 27 Mar 2012 19:14:07 +0200 Subject: 2.1.0beta3 missing man pages? In-Reply-To: (Nicholas Cole's message of "Wed, 14 Mar 2012 09:34:34 +0000") References: <4F6040CD.5050003@fifthhorseman.net> <878vj35yar.fsf@vigenere.g10code.de> Message-ID: <877gy6t19c.fsf@vigenere.g10code.de> On Wed, 14 Mar 2012 10:34, nicholas.cole at gmail.com said: > Could we have a 'DETAILS' like file in 2.1 describing what all the > various bits of the system do? Even as someone who has followed gpg Yeah, I agree that an architecture chapter in the manual would be very helpful. This is now bug#1395. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue Mar 27 19:47:50 2012 From: wk at gnupg.org (Werner Koch) Date: Tue, 27 Mar 2012 19:47:50 +0200 Subject: 2.1.0beta3: make check fails on test 17 of common/t-timestuff when TZ=America/New_York In-Reply-To: <4F611F7D.1000502@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 14 Mar 2012 18:45:17 -0400") References: <4F6019DC.4060701@fifthhorseman.net> <87haxr5ysv.fsf@vigenere.g10code.de> <4F611F7D.1000502@fifthhorseman.net> Message-ID: <87398uszp5.fsf@vigenere.g10code.de> On Wed, 14 Mar 2012 23:45, dkg at fifthhorseman.net said: > for the 13th month of 2037, which is in fact Jan 2038, at the > expiration of the unix epoch (what the wall clock says when the epoch > ends depends on your TZ). I think the comment above is mistaken. Good catch. I fixed that silly error. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wking at drexel.edu Tue Mar 27 20:00:44 2012 From: wking at drexel.edu (W. Trevor King) Date: Tue, 27 Mar 2012 14:00:44 -0400 Subject: gpgme-tool documentation updates In-Reply-To: <87mx72t4zh.fsf@vigenere.g10code.de> <4F71CF60.2040403@ruhr-uni-bochum.de> Message-ID: <20120327180044.GA30604@odin.tremily.us> On Tue, Mar 27, 2012 at 04:32:00PM +0200, Marcus Brinkmann wrote: > For substantial contributions, we face the legal issues. GPGME is > currently copyright by g10 Code GmbH, the company by GnuPG author > Werner Koch. GPGME used to be GPLv2 or later for a long time, but > eventually we did a license change to the more liberal LGPLv2.1 or > later, so more people can use it. > > We currently do not have formal copyright assignments for GPGME > prepared, but, informally, would you be ok with it if in the future we > want to change the GPGME license to another FSF-approved free software > license? I would be ok with any free license, although I'd prefer at least LGPL. On Tue, Mar 27, 2012 at 05:53:38PM +0200, Werner Koch wrote: > Please send patches. That is easier for us to handle. If they are too > long, please send them by private mail to Marcus. Well, the new help strings is 160 new lines, not that there's anything complicated going on, so maybe that qualifies as too long ;). > Note, that gpg-tool has an online help system. Most of the > documentation can go there. I assume you mean the `hlp_*` strings in `gpgme-tool.c`, which is what I was fleshing out. I think it would also be useful to add some comments to the texinfo in `doc/` giving a general overview, but I have little texinfo-fu ;). 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. Cheers, Trevor p.s. Marcus, you signed your last message with FCD2A293, which I haven't been able to find anywhere. Your only keys on pool.sks-keyservers.net seem to be 87978569 and 36E7CD09. Could you point me to a copy of your key? -- 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 Wed Mar 28 18:06:23 2012 From: beebe at math.utah.edu (Nelson H. F. Beebe) Date: Wed, 28 Mar 2012 10:06:23 -0600 (MDT) Subject: [gnupg-devel] gnupg-2.0.19: common/estream.c mixes void and int Message-ID: 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/ - ------------------------------------------------------------------------------- From wk at gnupg.org Fri Mar 30 15:18:08 2012 From: wk at gnupg.org (Werner Koch) Date: Fri, 30 Mar 2012 15:18:08 +0200 Subject: [gnupg-devel] gnupg-2.0.19: common/estream.c mixes void and int In-Reply-To: (Nelson H. F. Beebe's message of "Wed, 28 Mar 2012 10:06:23 -0600 (MDT)") References: Message-ID: <87boneqlbj.fsf@vigenere.g10code.de> On Wed, 28 Mar 2012 18:06, beebe at math.utah.edu said: > 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. okay, the fix is: # define ESTREAM_MUTEX_LOCK(mutex) \ (estream_pth_killed ? dummy_mutex_call_void ((mutex)) \ - : pth_mutex_acquire (&(mutex), 0, NULL)) + : (void)pth_mutex_acquire (&(mutex), 0, NULL)) > 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. Hmmm, I can see the problem. We have: # define ESTREAM_MUTEX_TRYLOCK(mutex) \ (estream_pth_killed ? dummy_mutex_call_int ((mutex)) \ : ((pth_mutex_acquire (&(mutex), 1, NULL) == TRUE)? 0:-1)) #define ESTREAM_TRYLOCK(stream) ESTREAM_MUTEX_TRYLOCK (stream->intern->lock) int es_ftrylockfile (estream_t stream) { return ESTREAM_TRYLOCK (stream); } Thus, we either call a dummy functions which returns an int (dummy_mutex_call_int) or the result of the condition which is eitehr o or -1. > % ./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. The help string is wrong. We need Pth. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From komh78 at gmail.com Sat Mar 31 13:21:58 2012 From: komh78 at gmail.com (KO Myung-Hun) Date: Sat, 31 Mar 2012 20:21:58 +0900 Subject: [PATCH libgpg-error] Add OS/2 supports In-Reply-To: <1331301069-42800-1-git-send-email-komh@chollian.net> References: <1331301069-42800-1-git-send-email-komh@chollian.net> Message-ID: <4F76E8D6.2000208@chollian.net> KO Myung-Hun wrote: > --- > configure.ac | 8 ++++++++ > src/Makefile.am | 8 ++++++-- > 2 files changed, 14 insertions(+), 2 deletions(-) > > diff --git a/configure.ac b/configure.ac > index ee42f9e..bd0c351 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -89,6 +89,7 @@ AC_ARG_VAR(CC_FOR_BUILD,[build system C compiler]) > have_w32_system=no > have_w64_system=no > have_w32ce_system=no > +have_os2_system=no > case "${host}" in > x86_64-*mingw32*) > have_w32_system=yes > @@ -101,6 +102,9 @@ case "${host}" in > *-mingw32*) > have_w32_system=yes > ;; > + *-os2*) > + have_os2_system=yes > + ;; > *) > ;; > esac > @@ -179,6 +183,10 @@ AM_CONDITIONAL(HAVE_W32_SYSTEM, test "$have_w32_system" = yes) > AM_CONDITIONAL(HAVE_W64_SYSTEM, test "$have_w64_system" = yes) > AM_CONDITIONAL(HAVE_W32CE_SYSTEM, test "$have_w32ce_system" = yes) > > +if test "$have_os2_system" = yes; then > + AC_DEFINE(HAVE_OS2_SYSTEM,1,[Defined if we run on an OS/2 API based system]) > +fi > +AM_CONDITIONAL(HAVE_OS2_SYSTEM, test "$have_os2_system" = yes) > > AC_ARG_ENABLE(languages, > [ --disable-languages do not build support for other languages than C]) > diff --git a/src/Makefile.am b/src/Makefile.am > index 518a4c0..5a1b49d 100644 > --- a/src/Makefile.am > +++ b/src/Makefile.am > @@ -84,7 +84,11 @@ intllibs = > else > arch_sources = > gpg_error_res = > +if HAVE_OS2_SYSTEM > +no_undefined = -no-undefined > +else > no_undefined = > +endif > export_symbols = > install-def-file: > uninstall-def-file: > @@ -167,7 +171,7 @@ gpg-error.def: Makefile gpg-error.def.in > > # It is correct to use $(CC_FOR_BUILD) here. We want to run the > # program at build time. > -mkerrcodes: mkerrcodes.c mkerrcodes.h Makefile > +mkerrcodes$(EXEEXT): mkerrcodes.c mkerrcodes.h Makefile > $(CC_FOR_BUILD) -I. -I$(srcdir) -o $@ $(srcdir)/mkerrcodes.c > > if HAVE_W32CE_SYSTEM > @@ -177,7 +181,7 @@ mkw32errmap: mkw32errmap.c mkw32errmap.tab.h Makefile > $(CC_FOR_BUILD) -I. -I$(srcdir) -o $@ $(srcdir)/mkw32errmap.c > endif > > -code-from-errno.h: mkerrcodes Makefile > +code-from-errno.h: mkerrcodes$(EXEEXT) Makefile > ./mkerrcodes | $(AWK) -f $(srcdir)/mkerrcodes2.awk >$@ > > errnos-sym.h: Makefile mkstrtable.awk errnos.in > -- > 1.7.3.2 Ping ? -- KO Myung-Hun Using Mozilla SeaMonkey 2.0.14 Under OS/2 Warp 4 for Korean with FixPak #15 On AMD ThunderBird 1GHz with 512 MB RAM Korean OS/2 User Community : http://www.ecomstation.co.kr