From mailinglisten at hauke-laging.de Thu Sep 1 15:57:41 2011 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 1 Sep 2011 15:57:41 +0200 Subject: protection against hardware attacks (RAM removal) Message-ID: <201109011557.42630.mailinglisten@hauke-laging.de> Hello, as probably most of you know it is possible to grab key material from a PC by powering off the system and immediate removal of the RAM and continuing its refresh in other hardware. The harder variant of the suspend to RAM problem... If the RAM is cooled down before powering off this works quite well. I just had an idea (I hope it's new...) how this risk could be reduced at least for applications which need their keys from time to time only, may be not suitable for disk encryption. If you remove the RAM information starts getting lost immediately. The longer it takes to start the refresh again and the higher the RAM temperature is the more information is lost. I you know where (approximately) in memory a key is stored and just a small part of it has been destroyed then it is not a problem to recover the key. Software cannot influence the size of the share of the information which gets lost as this is hardware stuff. But software can influence how much information (measured in bits and bytes) you need. My proposal is to increase this amount of memory so that even a small share of lost information is equivalent to a brute force resistant amount of bits. The keys could be expanded to several kilobytes of RAM (could be easily configured to the desired protection level) right after they have become available to GnuPG. I guess even something as trivial as XOR could be used to securely spread the key over more memory. Every time a crypto operation needs a secret key, the key is recovered from the expanded area, used and overwritten afterwards. That would make it very improbable that the key is available in RAM as clear data. There may be ways to trigger the use of secret keys over e network (i.e. send an encrypted email) but that can be solved elsewhere. And even then an attacker would have to be very lucky (and would have just one chance). If there are no task switches in between then the raw key data would probably never reach RAM (would be written and overwritten in the CPUs write back cache). Does anyone of you know whether there are features (or plans for such) addressing this problem with mainstream CPUs? Either in hardware or in software? Does Linux allow locking of pages in a L1 cache (in order to prevent the data from being written to RAM)? Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From jerome at jeromebaum.com Thu Sep 1 17:03:57 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 1 Sep 2011 17:03:57 +0200 Subject: protection against hardware attacks (RAM removal) In-Reply-To: <201109011557.42630.mailinglisten@hauke-laging.de> References: <201109011557.42630.mailinglisten@hauke-laging.de> Message-ID: > The keys could be expanded to several kilobytes of RAM (could be easily > configured to the desired protection level) right after they have become > available to GnuPG. I guess even something as trivial as XOR could be used to > securely spread the key over more memory. The secure and well-studied version being the AONT (of key||padding, where padding is just a lot of random data). Though you need to carefully balance the size -- too small and it's not a significant help (i.e. data loss isn't fast enough), too big and it doesn't fit into the cache. About the context switches, won't going into system mode be enough? From mailinglisten at hauke-laging.de Thu Sep 1 17:15:46 2011 From: mailinglisten at hauke-laging.de (Hauke Laging) Date: Thu, 1 Sep 2011 17:15:46 +0200 Subject: protection against hardware attacks (RAM removal) In-Reply-To: References: <201109011557.42630.mailinglisten@hauke-laging.de> Message-ID: <201109011715.47417.mailinglisten@hauke-laging.de> Am Donnerstag, 1. September 2011, 17:03:57 schrieb Jerome Baum: > Though you need to carefully balance the size -- too small and it's > not a significant help (i.e. data loss isn't fast enough), too big and > it doesn't fit into the cache. There is no need for the expanded data to fit into the cache. Would not even make sense to cache it on normal systems as you hardly ever have crypto operations so quickly one after another that the cache data has NOT been trashed in the meantime. > About the context switches, won't going into system mode be enough? I have to admit that I don't know what "system mode" is. It would be nice to be able to implement something like that without the need for OS support. Hauke -- PGP: D44C 6A5B 71B0 427C CED3 025C BD7D 6D27 ECCB 5814 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 555 bytes Desc: This is a digitally signed message part. URL: From jerome at jeromebaum.com Thu Sep 1 17:39:13 2011 From: jerome at jeromebaum.com (Jerome Baum) Date: Thu, 1 Sep 2011 17:39:13 +0200 Subject: protection against hardware attacks (RAM removal) In-Reply-To: <201109011715.47417.mailinglisten@hauke-laging.de> References: <201109011557.42630.mailinglisten@hauke-laging.de> <201109011715.47417.mailinglisten@hauke-laging.de> Message-ID: >> Though you need to carefully balance the size -- too small and it's >> not a significant help (i.e. data loss isn't fast enough), too big and >> it doesn't fit into the cache. > > There is no need for the expanded data to fit into the cache. Would not even > make sense to cache it on normal systems as you hardly ever have crypto > operations so quickly one after another that the cache data has NOT been > trashed in the meantime. I was thinking along these lines: >>> Does Linux allow locking of pages in a L1 cache (in order to prevent the data from being written to RAM)? >> About the context switches, won't going into system mode be enough? > > I have to admit that I don't know what "system mode" is. It would be nice to > be able to implement something like that without the need for OS support. I only roughly recall this stuff but basically your average CPU can distinguish "system" vs. "user" mode. System mode is where your OS works, user mode is where the user works. :) The point being that system mode gives you a lot more privileges and I think that while in system mode, you don't get interrupted (in fact, system mode is where e.g. the scheduler would be running). I don't think there is any way to prevent a context-switch w/out OS support (read: root-level access). It's a security feature of the underlying OS that you can't "steal" the CPU. -- Jerome Baum Hessenweg 222 48432 Rheine GERMANY tel +49-1578-8434336 email jerome at jeromebaum.com web www.jeromebaum.com -- Einigkeit und Recht und Modeerscheinung -- PGP: A0E4 B2D4 94E6 20EE 85BA E45B 63E4 2BD8 C58C 753A PGP: 2C23 EBFF DF1A 840D 2351 F5F5 F25B A03F 2152 36DA -- http://five.sentenc.es From rjh at sixdemonbag.org Thu Sep 1 17:48:18 2011 From: rjh at sixdemonbag.org (Robert J. Hansen) Date: Thu, 01 Sep 2011 08:48:18 -0700 Subject: protection against hardware attacks (RAM removal) In-Reply-To: <201109011557.42630.mailinglisten@hauke-laging.de> References: <201109011557.42630.mailinglisten@hauke-laging.de> Message-ID: > I just had an idea (I hope it's new...) how this risk could be reduced at > least for applications which need their keys from time to time only, may > be not suitable for disk encryption. ObNotice: I'm not speaking for my employers, past or present. (Some of my prior jobs involved memory forensics, hence the note.) This idea has come up before and gets reimplemented every few years. It tends not to work. It is *theoretically* possible to do this, but in practice it's pointless. Imagine that for each and every bit you expand it out into a random 100-bit bitstring. If the bitstring has an even number of 1s then the encoded bit is 1: if it has an odd number of 1s the encoded bit is 0. Once you've created your bitstrings you then tweak a random bit in each bitstring, if needed. Presto: you've expanded the memory required by a factor of 100, and losing any one bit of the 100 will throw off the entire result. In practice, this doesn't gain us anything. If the attacker has physical access to the hardware it's a game-over condition. Further, attackers can defeat this pretty easily: closing the laptop lid, for instance, will force a hibernation and the OS will dump all memory to disk. Even if hibernation is disabled, a can of compressed air can be used to cool the chips prior to removal: do this and memory won't begin to degrade for a couple of minutes -- plenty of time to move the chips to a powered breadboard. Etc., etc. There are a whole lot of ways around this. If you're worried about an attacker lifting the RAM out of your system, your proper defense is to keep the attacker from lifting the RAM out of your system -- not trying to make the degradation curve work in your favor. From john.marshall at riverwillow.com.au Wed Sep 7 07:56:20 2011 From: john.marshall at riverwillow.com.au (John Marshall) Date: Wed, 7 Sep 2011 15:56:20 +1000 Subject: GnuPG 2.0.18 won't use libcurl Message-ID: <20110907055620.GB27801@rwpc13.mby.riverwillow.net.au> The 2.0.18 configure script test for libcurl is broken. The test program's '#include ' directive is missing its leading '#'. From config.log... configure:9374: checking whether libcurl is usable configure:9407: cc -o conftest -O -pipe -march=pentium4 -DLDAP_DEPRECATED -I/usr/local/include -I/usr/local/include -L/usr/local/lib conftest.c -L/usr/local/lib -lcurl >&5 conftest.c:46: error: expected '=', ',', ';', 'asm' or '__attribute__' before '<' token configure:9407: $? = 1 configure: failed program was: ---< snip >-- | /* end confdefs.h. */ | include | int | main () ---< snip >-- configure:9421: result: no It looks like the source of the problem is Line 144 in m4/libcurl.m4 but patching Line 9387 in the distribution's configure file was all I needed to do to correct the build. This doesn't actually break the build because the 'GnuPG curl-shim' kicks in when the build fails to use libcurl. I guess there are lots of 2.0.18 isntallations out there running with the curl-shim! The reason I tracked this down was that my 2.0.18 installation failed to resolve SRV records for the supplied keyserver name prior to attempting to query the keyserver via an HTTP proxy: there was no corresponding A record and the query would fail. It had worked fine previously, and still worked fine from a 1.4.11 installation. I enabled the debug keyserver-option on both the 1.4.11 and 2.0.18 systems and noted that the 2.0.18 system was showing "curl version = GnuPG curl-shim". Thank you for maintaining this great software. Regards, -- John Marshall -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From sms at antinode.info Thu Sep 8 06:33:14 2011 From: sms at antinode.info (Steven M. Schweda) Date: Wed, 7 Sep 2011 23:33:14 -0500 (CDT) Subject: GnuPG 1.4.11 v. VMS batch mode Message-ID: <11090723331404_2020D6C7@antinode.info> Greetings: A victim of my GnuPG 1.4.11 for VMS kit recently ran into an interesting problem. A DCL procedure (think: "shell script") works when run interactively, but loops when run as a batch job (think: "at/cron job"?). I think that I've figured out what's happening, and I thought that I'd get a consultation on a proposed fix. The (apparently harmless) problem command looks like this: pipe gpg -d -o bat.out --passphrase-fd 0 login.com-gpg < pp.txt The problem seems (to me, at the moment) to be bad general code, but the problem case may never occur on a UNIX(-like) system, so perhaps no one else would have noticed it. During the program initialization, util/ttyio.c:init_ttyfp() gets called. It uses ctermid() to get the name of the controlling terminal. For a batch job on VMS, this comes back as the disk name (which is what I'd guess never happens elsewhere). The program tries to fopen() this, which fails, because it's a disk, not a terminal. The program then tries to write a "cannot open" error message to the terminal, but it won't do that until it gets the terminal I/O set up properly, and for that it calls init_ttyfp(). Lather, rinse, ... The following change seems to solve the looping in a plausible/harmless way (slightly enhancing the message, because a typical VMS user might not otherwise guess why anyone is trying to open a disk device): --- util/ttyio.c_orig 2010-09-28 04:39:05 -0500 +++ util/ttyio.c 2011-09-07 22:19:34 -0500 @@ -185,7 +185,8 @@ #else ttyfp = batchmode? stderr : fopen( tty_get_ttyname (), "r+"); if( !ttyfp ) { - log_error("cannot open `%s': %s\n", + initialized = 1; /* Don't come back again, ever. */ + log_error("cannot open tty, `%s': %s\n", tty_get_ttyname (), strerror(errno) ); exit(2); } The victim still needs to specify option(s) like "--batch" to avoid the fatal "cannot open [tty]" error, but this way it dies promptly, emitting a message like: gpg: cannot open tty, `_ALP$DKC0:': no such file or directory which, while not wonderfully informative, certainly beats an endless loop (and no message). On VMS, it should be relatively easy to check the process mode during initialization, and set the "--batch" flag ("batchmode"?) automatically for a batch job. I haven't yet thought of a good reason not to do this, but I'm always open to a good counter-argument. Any wisdom would be gratefully received. ------------------------------------------------------------------------ Steven M. Schweda sms at antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 From sms at antinode.info Fri Sep 9 05:52:53 2011 From: sms at antinode.info (Steven M. Schweda) Date: Thu, 8 Sep 2011 22:52:53 -0500 (CDT) Subject: GnuPG 1.4.11 v. VMS batch mode Message-ID: <11090822525316_2020DAC5@antinode.info> > On VMS, it should be relatively easy to check the process mode during > initialization, and set the "--batch" flag ("batchmode"?) automatically > for a batch job. I haven't yet thought of a good reason not to do this, > but I'm always open to a good counter-argument. This seems to work (with the associated changes to various VMS-specific files in the "vms" and "vmslib" subdirectories: --- g10/gpg.c_orig 2010-07-05 04:17:37 -0500 +++ g10/gpg.c 2011-09-08 13:37:06 -0500 @@ -40,6 +40,10 @@ #include #endif +#ifdef __VMS +# include "vms.h" +#endif + #define INCLUDED_BY_MAIN_MODULE 1 #include "packet.h" #include "iobuf.h" @@ -1872,6 +1876,14 @@ opt.lock_once = 1; #endif /* __riscos__ */ +#ifdef __VMS + /* On VMS, set the default value of the "--[no-]batch" flag + * according to the actual process mode. The user can override this + * with an explicit command-line "--[no-]batch" option. + */ + opt.batch = batch_mode_vms(); +#endif + reopen_std(); trap_unaligned(); secmem_set_flags( secmem_get_flags() | 2 ); /* suspend warnings */ I thought about trying to hide this stuff in some VMS-specific place, to avoid adding VMS-specific clutter in the main thing, but it made more sense to me to set opt.batch this way, in the same neighborhood as the normal opt.xxxx-setting code. Comments welcome, as usual. ------------------------------------------------------------------------ Steven M. Schweda sms at antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 From wk at gnupg.org Mon Sep 12 15:15:00 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 Sep 2011 15:15:00 +0200 Subject: GnuPG 1.4.11 v. VMS batch mode In-Reply-To: <11090723331404_2020D6C7@antinode.info> (Steven M. Schweda's message of "Wed, 7 Sep 2011 23:33:14 -0500 (CDT)") References: <11090723331404_2020D6C7@antinode.info> Message-ID: <87fwk1x5pn.fsf@vigenere.g10code.de> On Thu, 8 Sep 2011 06:33, sms at antinode.info said: > - log_error("cannot open `%s': %s\n", > + initialized = 1; /* Don't come back again, ever. */ > + log_error("cannot open tty, `%s': %s\n", > tty_get_ttyname (), strerror(errno) ); > exit(2); I added ttyfp = stderr so that it has a defined value. > On VMS, it should be relatively easy to check the process mode during > initialization, and set the "--batch" flag ("batchmode"?) automatically > for a batch job. I haven't yet thought of a good reason not to do this, I'll also apply your other patch. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From sms at antinode.info Mon Sep 12 15:29:09 2011 From: sms at antinode.info (Steven M. Schweda) Date: Mon, 12 Sep 2011 08:29:09 -0500 (CDT) Subject: GnuPG 1.4.11 v. VMS batch mode Message-ID: <11091208290974_2020D6C7@antinode.info> From: Werner Koch > I added > ttyfp = stderr > so that it has a defined value. > I'll also apply your other patch. Sounds good to me. Thanks. ------------------------------------------------------------------------ Steven M. Schweda sms at antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 From wk at gnupg.org Mon Sep 12 15:38:10 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 Sep 2011 15:38:10 +0200 Subject: GnuPG 2.0.18 won't use libcurl In-Reply-To: <20110907055620.GB27801@rwpc13.mby.riverwillow.net.au> (John Marshall's message of "Wed, 7 Sep 2011 15:56:20 +1000") References: <20110907055620.GB27801@rwpc13.mby.riverwillow.net.au> Message-ID: <87boupx4n1.fsf@vigenere.g10code.de> On Wed, 7 Sep 2011 07:56, john.marshall at riverwillow.com.au said: > The 2.0.18 configure script test for libcurl is broken. The test > program's '#include ' directive is missing its leading '#'. Sorry. That was my fault. Fixed for 2.0 and master Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jim at meyering.net Mon Sep 19 21:09:42 2011 From: jim at meyering.net (Jim Meyering) Date: Mon, 19 Sep 2011 21:09:42 +0200 Subject: link failure when building against latest libgcrypt Message-ID: <87sjns2vt5.fsf@rho.meyering.net> Hi, Just a quick FYI that building gnupg (latest from git), using the latest sources of libgcrypt leads to link failures like this: /w/gnupg/g10/mainproc.c:712: undefined reference to `gcry_md_start_debug' /w/gnupg/g10/mainproc.c:714: undefined reference to `gcry_md_start_debug' mainproc.o: In function `proc_tree': ... That's due to this commit in libgcrypt: commit 889a25ed3333d1d7657b4b59ae21f6e8458f9027 Author: Werner Koch Date: Thu Sep 15 18:24:23 2011 +0200 Removed deprecated debug macros. While I wait for gnupg to catch up, I worked around it by adding this line to config.h: #define gcry_md_start_debug(a,b) /*empty */ From wk at gnupg.org Tue Sep 20 10:00:05 2011 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Sep 2011 10:00:05 +0200 Subject: link failure when building against latest libgcrypt In-Reply-To: <87sjns2vt5.fsf@rho.meyering.net> (Jim Meyering's message of "Mon, 19 Sep 2011 21:09:42 +0200") References: <87sjns2vt5.fsf@rho.meyering.net> Message-ID: <87iponskuk.fsf@vigenere.g10code.de> On Mon, 19 Sep 2011 21:09, jim at meyering.net said: > /w/gnupg/g10/mainproc.c:714: undefined reference to `gcry_md_start_debug' I adjusted gnupg. Thanks. FWIW: The next Libgcrypt version will have a changed ABI and some cleanups in the API. In particular the entire module registration system is gone, the gcry_ac functions are gone and the threading model setup calls won't be needed anymore. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From jim at meyering.net Tue Sep 20 16:26:37 2011 From: jim at meyering.net (Jim Meyering) Date: Tue, 20 Sep 2011 16:26:37 +0200 Subject: [PATCH] avoid use of freed pointer Message-ID: <87obyfs31e.fsf@rho.meyering.net> Without this patch, pk2 would be freed twice. >From 2a18a4b757e0896e738fefbbaa8ff8c23a9edf89 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Tue, 20 Sep 2011 16:20:39 +0200 Subject: [PATCH] avoid use of freed pointer If we free pk2 at the top of the for-loop, set it to NULL so that we don't free it again just before returning. * revoke.c (gen_desig_revoke): Don't use pk2 after freeing it. --- g10/ChangeLog | 7 +++++++ g10/revoke.c | 5 ++++- 2 files changed, 11 insertions(+), 1 deletions(-) diff --git a/g10/ChangeLog b/g10/ChangeLog index be2ad0b..8ae5747 100644 --- a/g10/ChangeLog +++ b/g10/ChangeLog @@ -1,3 +1,10 @@ +2011-09-20 Jim Meyering + + avoid use of freed pointer + If we free pk2 at the top of the for-loop, set it to NULL + so that we don't free it again just before returning. + * revoke.c (gen_desig_revoke): Don't use pk2 after freeing it. + 2011-09-20 Werner Koch * sign.c (sign_file, clearsign_file, sign_symencrypt_file): diff --git a/g10/revoke.c b/g10/revoke.c index c18dfb9..2c696cc 100644 --- a/g10/revoke.c +++ b/g10/revoke.c @@ -263,7 +263,10 @@ gen_desig_revoke( const char *uname, strlist_t locusr ) SK_LIST list; if (pk2) - free_public_key (pk2); + { + free_public_key (pk2); + pk2 = NULL; + } if(sk_list) { -- 1.7.7.rc0.362.g5a14 From jim at meyering.net Tue Sep 20 16:35:30 2011 From: jim at meyering.net (Jim Meyering) Date: Tue, 20 Sep 2011 16:35:30 +0200 Subject: [PATCH] tests: avoid use of freed pointer Message-ID: <87fwjrs2ml.fsf@rho.meyering.net> [spotted by coverity] This is only in tests/, but easy to fix, so... I've included extra context so you can see how var->value would be used in the following atoi call. >From cf9ae83fd2da8d7a289b048ef0feed4096f6d263 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Tue, 20 Sep 2011 16:32:59 +0200 Subject: [PATCH] avoid use of free'd pointer * asschk.c (set_type_var): Set var->value to NULL after freeing it, to avoid subsequent use of freed pointer. --- tests/ChangeLog | 6 ++++++ tests/asschk.c | 5 ++++- 2 files changed, 10 insertions(+), 1 deletions(-) diff --git a/tests/ChangeLog b/tests/ChangeLog index b2e95f3..aa93f07 100644 --- a/tests/ChangeLog +++ b/tests/ChangeLog @@ -1,6 +1,12 @@ +2011-09-20 Jim Meyering + + avoid use of free'd pointer + * asschk.c (set_type_var): Set var->value to NULL after freeing it, + to avoid subsequent use of freed pointer. + 2009-10-13 Werner Koch * asschk.c (die): Replace this vararg macro by C-89 compliant macros die_0, die_1, die_2 and die 3. Change all callers. Reported by Nelson H. F. Beebe. diff --git a/tests/asschk.c b/tests/asschk.c index 3eb2621..c0108e7 100644 --- a/tests/asschk.c +++ b/tests/asschk.c @@ -511,13 +511,16 @@ set_type_var (const char *name, const char *value, VARTYPE type) var = xcalloc (1, sizeof *var + strlen (name)); strcpy (var->name, name); var->next = variable_list; variable_list = var; } else - free (var->value); + { + free (var->value); + var->value = NULL; + } if (var->type == VARTYPE_FD && var->value) { int fd; fd = atoi (var->value); -- 1.7.7.rc0.362.g5a14 From wk at gnupg.org Tue Sep 20 19:08:57 2011 From: wk at gnupg.org (Werner Koch) Date: Tue, 20 Sep 2011 19:08:57 +0200 Subject: [PATCH] avoid use of freed pointer In-Reply-To: <87obyfs31e.fsf@rho.meyering.net> (Jim Meyering's message of "Tue, 20 Sep 2011 16:26:37 +0200") References: <87obyfs31e.fsf@rho.meyering.net> Message-ID: <87wrd3qgye.fsf@vigenere.g10code.de> Applied both. Thanks, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From ml at schoenitzer.de Wed Sep 21 15:14:48 2011 From: ml at schoenitzer.de (Michael Florian =?iso-8859-1?q?Sch=F6nitzer?=) Date: Wed, 21 Sep 2011 13:14:48 +0000 (UTC) Subject: gpgkeymgr 0.3 released Message-ID: I've released version 0.3 of my tool gpgkeymgr today. With gpgkeymgr you can clean up and manage your GnuPGP-keyring, by removing old and unnecessary keys. There haven't been any new bigger features, but I have an French translation (thanks to jbar), German translation of program and manpage, some smaller improvements and probably most important an improved makefile working on more different Systems without problems. Link: http://nudin.github.com/GnuPGP-Tools/ Regards, Michael Sch?nitzer -- Michael F. Sch?nitzer Mail: michael ?t schoenitzer.de Jabber: Schoenitzer at jabber.piratenpartei.de From flameeyes at flameeyes.eu Thu Sep 22 15:45:11 2011 From: flameeyes at flameeyes.eu (=?UTF-8?q?Diego=20Elio=20Petten=C3=B2?=) Date: Thu, 22 Sep 2011 15:45:11 +0200 Subject: [PATCH] gpg-error-config: handle /usr/lib64, /lib64 just like /usr/lib and /lib Message-ID: <1316699111-16206-1-git-send-email-flameeyes@flameeyes.eu> Distributions such as Gentoo Linux use /usr/lib64 for system libraries on multilib setups, so in those cases, ignore the libraries as well. Signed-off-by: Diego Elio Petten? --- src/gpg-error-config.in | 9 ++++++--- 1 files changed, 6 insertions(+), 3 deletions(-) diff --git a/src/gpg-error-config.in b/src/gpg-error-config.in index 14f0625..df27f0a 100644 --- a/src/gpg-error-config.in +++ b/src/gpg-error-config.in @@ -69,9 +69,12 @@ while test $# -gt 0; do output="$output @GPG_ERROR_CONFIG_CFLAGS@" ;; --libs) - if test "x$libdir" != "x/usr/lib" -a "x$libdir" != "x/lib"; then - output="$output -L$libdir" - fi + case "$libdir" in + /usr/lib|/usr/lib64|/lib|/lib64) ;; + *) + output="$output -L$libdir" + ;; + esac output="$output @GPG_ERROR_CONFIG_LIBS@" ;; --host) -- 1.7.6.1 From flameeyes at flameeyes.eu Thu Sep 22 15:55:33 2011 From: flameeyes at flameeyes.eu (=?UTF-8?q?Diego=20Elio=20Petten=C3=B2?=) Date: Thu, 22 Sep 2011 15:55:33 +0200 Subject: [PATCH] gpgsm-gencert.sh: make sure not to abort after creating temp file. Message-ID: <1316699733-17273-1-git-send-email-flameeyes@flameeyes.eu> From: Diego Elio Petten? Signed-off-by: Diego Elio Petten? Signed-off-by: Diego Elio Petten? --- tools/gpgsm-gencert.sh | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/tools/gpgsm-gencert.sh b/tools/gpgsm-gencert.sh index b209c8e..e7c812f 100755 --- a/tools/gpgsm-gencert.sh +++ b/tools/gpgsm-gencert.sh @@ -178,10 +178,10 @@ Key-Length: $KEY_LENGTH Key-Usage: $KEY_USAGE Name-DN: $NAME EOF -[ -n "$KEY_GRIP" ] && echo "Key-Grip: $KEY_GRIP" -[ -n "$EMAIL_ADDRESSES" ] && echo "$EMAIL_ADDRESSES" -[ -n "$DNS_ADDRESSES" ] && echo "$DNS_ADDRESSES" -[ -n "$URI_ADDRESSES" ] && echo "$URI_ADDRESSES" +[ -n "$KEY_GRIP" ] && echo "Key-Grip: $KEY_GRIP" || true +[ -n "$EMAIL_ADDRESSES" ] && echo "$EMAIL_ADDRESSES" || true +[ -n "$DNS_ADDRESSES" ] && echo "$DNS_ADDRESSES" || true +[ -n "$URI_ADDRESSES" ] && echo "$URI_ADDRESSES" || true ) > "$file_parameter" -- 1.7.6.1 From wk at gnupg.org Thu Sep 22 20:43:13 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Sep 2011 20:43:13 +0200 Subject: [PATCH] gpg-error-config: handle /usr/lib64, /lib64 just like /usr/lib and /lib In-Reply-To: <1316699111-16206-1-git-send-email-flameeyes@flameeyes.eu> ("Diego Elio =?utf-8?Q?Petten=C3=B2=22's?= message of "Thu, 22 Sep 2011 15:45:11 +0200") References: <1316699111-16206-1-git-send-email-flameeyes@flameeyes.eu> Message-ID: <87litgo1tq.fsf@vigenere.g10code.de> On Thu, 22 Sep 2011 15:45, flameeyes at flameeyes.eu said: > Distributions such as Gentoo Linux use /usr/lib64 for system libraries on > multilib setups, so in those cases, ignore the libraries as well. Applied. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu Sep 22 20:40:23 2011 From: wk at gnupg.org (Werner Koch) Date: Thu, 22 Sep 2011 20:40:23 +0200 Subject: [PATCH] gpgsm-gencert.sh: make sure not to abort after creating temp file. In-Reply-To: <1316699733-17273-1-git-send-email-flameeyes@flameeyes.eu> ("Diego Elio =?utf-8?Q?Petten=C3=B2=22's?= message of "Thu, 22 Sep 2011 15:55:33 +0200") References: <1316699733-17273-1-git-send-email-flameeyes@flameeyes.eu> Message-ID: <87pqiso1yg.fsf@vigenere.g10code.de> Hi, we will remove this old shell script anyway. gpgsm --gen-key replaces it, works on Windows and has better error indications. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From vapier at gentoo.org Fri Sep 23 05:37:21 2011 From: vapier at gentoo.org (Mike Frysinger) Date: Thu, 22 Sep 2011 23:37:21 -0400 Subject: [PATCH 1/2] ignore more generated files Message-ID: <1316749042-14507-1-git-send-email-vapier@gentoo.org> Signed-off-by: Mike Frysinger --- .gitignore | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 45 insertions(+), 0 deletions(-) diff --git a/.gitignore b/.gitignore index 6b8851e..377a67d 100644 --- a/.gitignore +++ b/.gitignore @@ -1,7 +1,52 @@ +*~ +*.a +*.gmo +*.la +*.lo +*.o + +*.diff +*.orig +*.patch +*.rej + +.deps +.libs + +Makefile Makefile.in aclocal.m4 autom4te.cache/ configure +config.h config.h.in +config.log +config.status +libtool +stamp-h1 + +lang/cl/gpg-error-codes.lisp +lang/cl/gpg-error.asd + +po/POTFILES +po/stamp-po + +src/code-from-errno.h +src/code-to-errno.h src/err-codes.h +src/err-codes-sym.h src/err-sources.h +src/err-sources-sym.h +src/errnos-sym.h +src/extra-h.in +src/gpg-error +src/gpg-error-config +src/gpg-error.def +src/gpg-error.h +src/mkerrcodes +src/mkerrcodes.h +src/mkw32errmap.map.c +src/versioninfo.rc + +tests/t-strerror +tests/t-syserror -- 1.7.6.1 From vapier at gentoo.org Fri Sep 23 05:37:22 2011 From: vapier at gentoo.org (Mike Frysinger) Date: Thu, 22 Sep 2011 23:37:22 -0400 Subject: [PATCH 2/2] add pkg-config support In-Reply-To: <1316749042-14507-1-git-send-email-vapier@gentoo.org> References: <1316749042-14507-1-git-send-email-vapier@gentoo.org> Message-ID: <1316749042-14507-2-git-send-email-vapier@gentoo.org> This moves gpg-error into the pkg-config world which is a lot easier to work with than random foo-config scripts. This also implicitly fixes the -L behavior regardless of the ABI in use which the previous commit to this file tried to do but failed. The old config script is kept due to the number of packages out there that still rely on it, but it is just a wrapper to the pkg-config file. Once we get those packages updated to use pkg-config too, we can drop this wrapper. Signed-off-by: Mike Frysinger --- .gitignore | 1 + configure.ac | 7 ++++ src/Makefile.am | 4 ++- src/gpg-error-config.in | 90 +++++++++------------------------------------- src/gpg-error.pc.in | 20 ++++++++++ 5 files changed, 49 insertions(+), 73 deletions(-) create mode 100644 src/gpg-error.pc.in diff --git a/.gitignore b/.gitignore index 377a67d..9e58db5 100644 --- a/.gitignore +++ b/.gitignore @@ -43,6 +43,7 @@ src/gpg-error src/gpg-error-config src/gpg-error.def src/gpg-error.h +src/gpg-error.pc src/mkerrcodes src/mkerrcodes.h src/mkw32errmap.map.c diff --git a/configure.ac b/configure.ac index a2ad1dd..987811c 100644 --- a/configure.ac +++ b/configure.ac @@ -151,6 +151,7 @@ AC_SUBST(GPG_ERROR_CONFIG_CFLAGS) AC_SUBST(GPG_ERROR_CONFIG_ISUBDIRAFTER) AC_SUBST(GPG_ERROR_CONFIG_HOST) AC_CONFIG_FILES([src/gpg-error-config], [chmod +x src/gpg-error-config]) +AC_CONFIG_FILES([src/gpg-error.pc]) # Special defines for certain platforms @@ -181,6 +182,12 @@ 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) +# Note: -idirafter is a gcc extension. It is only used on +# systems where gcc is the only compiler we support. +if test "$GPG_ERROR_CONFIG_ISUBDIRAFTER" != ""; then + GPG_ERROR_CONFIG_CFLAGS=`printf ' -idirafter ${includedir}/%s' $GPG_ERROR_CONFIG_ISUBDIRAFTER` +fi + 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..6a36a00 100644 --- a/src/Makefile.am +++ b/src/Makefile.am @@ -35,6 +35,8 @@ bin_PROGRAMS = gpg-error lib_LTLIBRARIES = libgpg-error.la include_HEADERS = gpg-error.h bin_SCRIPTS = gpg-error-config +pkgconfigdir = $(libdir)/pkgconfig +pkgconfig_DATA = gpg-error.pc m4datadir = $(datadir)/aclocal m4data_DATA = gpg-error.m4 @@ -43,7 +45,7 @@ EXTRA_DIST = mkstrtable.awk err-sources.h.in err-codes.h.in \ mkerrcodes.awk mkerrcodes1.awk mkerrcodes2.awk mkerrcodes.c \ mkheader.awk gpg-error.h.in mkw32errmap.c w32-add.h w32ce-add.h \ err-sources.h err-codes.h gpg-error-config.in gpg-error.m4 \ - gpg-error.def.in versioninfo.rc.in + gpg-error.def.in versioninfo.rc.in gpg-error.pc.in BUILT_SOURCES = err-sources.h err-codes.h code-to-errno.h code-from-errno.h \ err-sources-sym.h err-codes-sym.h errnos-sym.h gpg-error.h \ diff --git a/src/gpg-error-config.in b/src/gpg-error-config.in index df27f0a..b6d7c57 100644 --- a/src/gpg-error-config.in +++ b/src/gpg-error-config.in @@ -9,18 +9,20 @@ # WITHOUT ANY WARRANTY, to the extent permitted by law; without even the # implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. - -prefix=@prefix@ -exec_prefix=@exec_prefix@ -includedir=@includedir@ -libdir=@libdir@ -isubdirafter="@GPG_ERROR_CONFIG_ISUBDIRAFTER@" - -output="" - -usage() -{ - cat <&2 -fi - -while test $# -gt 0; do - case "$1" in - -*=*) - optarg=`echo "$1" | sed 's/[-_a-zA-Z0-9]*=//'` - ;; - *) - optarg= - ;; - esac - - case $1 in - --prefix) - output="$output $prefix" - ;; - --exec-prefix) - output="$output $exec_prefix" - ;; - --version) - echo "@VERSION@" - exit 0 - ;; - --cflags) - if test "x$includedir" != "x/usr/include" -a "x$includedir" != "x/include"; then - output="$output -I$includedir" - fi - # Note: -idirafter is a gcc extension. It is only used on - # systems where gcc is the only compiler we support. - for i in $isubdirafter; do - output="$output -idirafter ${includedir}/${i}" - done - output="$output @GPG_ERROR_CONFIG_CFLAGS@" - ;; - --libs) - case "$libdir" in - /usr/lib|/usr/lib64|/lib|/lib64) ;; - *) - output="$output -L$libdir" - ;; - esac - output="$output @GPG_ERROR_CONFIG_LIBS@" - ;; - --host) - echo "@GPG_ERROR_CONFIG_HOST@" - exit 0 - ;; - *) - usage 1 1>&2 - ;; - esac - shift -done - -echo $output + exit 1 + ;; +esac +exec ${PKG_CONFIG:-pkg-config} gpg-error ${flag} diff --git a/src/gpg-error.pc.in b/src/gpg-error.pc.in new file mode 100644 index 0000000..64278d2 --- /dev/null +++ b/src/gpg-error.pc.in @@ -0,0 +1,20 @@ +# Copyright (C) 1999, 2002, 2003, 2011 Free Software Foundation, Inc. +# +# This file is free software; as a special exception the author gives +# unlimited permission to copy and/or distribute it, with or without +# modifications, as long as this notice is preserved. +# +# This file is distributed in the hope that it will be useful, but +# WITHOUT ANY WARRANTY, to the extent permitted by law; without even the +# implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. + +prefix=@prefix@ +exec_prefix=@exec_prefix@ +includedir=@includedir@ +libdir=@libdir@ + +Name: @PACKAGE_NAME@ +Description: small library that defines common error values for all GnuPG components +Version: @PACKAGE_VERSION@ +Libs: -L${libdir} @GPG_ERROR_CONFIG_LIBS@ +Cflags: -I${includedir} @GPG_ERROR_CONFIG_CFLAGS@ -- 1.7.6.1 From wk at gnupg.org Fri Sep 23 10:02:19 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 23 Sep 2011 10:02:19 +0200 Subject: [PATCH 2/2] add pkg-config support In-Reply-To: <1316749042-14507-2-git-send-email-vapier@gentoo.org> (Mike Frysinger's message of "Thu, 22 Sep 2011 23:37:22 -0400") References: <1316749042-14507-1-git-send-email-vapier@gentoo.org> <1316749042-14507-2-git-send-email-vapier@gentoo.org> Message-ID: <87hb43ofec.fsf@vigenere.g10code.de> On Fri, 23 Sep 2011 05:37, vapier at gentoo.org said: > This moves gpg-error into the pkg-config world which is a lot easier I mentioned it several times in the past: We don't want to support pkg-config. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Fri Sep 23 10:02:45 2011 From: wk at gnupg.org (Werner Koch) Date: Fri, 23 Sep 2011 10:02:45 +0200 Subject: [PATCH 1/2] ignore more generated files In-Reply-To: <1316749042-14507-1-git-send-email-vapier@gentoo.org> (Mike Frysinger's message of "Thu, 22 Sep 2011 23:37:21 -0400") References: <1316749042-14507-1-git-send-email-vapier@gentoo.org> Message-ID: <87d3erofdm.fsf@vigenere.g10code.de> Hi, please use VPATH builds. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From martin at martinpaljak.net Fri Sep 23 13:54:32 2011 From: martin at martinpaljak.net (Martin Paljak) Date: Fri, 23 Sep 2011 14:54:32 +0300 Subject: [PATCH 2/2] add pkg-config support In-Reply-To: <87hb43ofec.fsf@vigenere.g10code.de> References: <1316749042-14507-1-git-send-email-vapier@gentoo.org> <1316749042-14507-2-git-send-email-vapier@gentoo.org> <87hb43ofec.fsf@vigenere.g10code.de> Message-ID: On Fri, Sep 23, 2011 at 11:02, Werner Koch wrote: > On Fri, 23 Sep 2011 05:37, vapier at gentoo.org said: >> This moves gpg-error into the pkg-config world which is a lot easier > > I mentioned it several times in the past: We don't want to support > pkg-config. Why? Who is "we" ? Best, Martin From luca at pca.it Mon Sep 19 20:33:13 2011 From: luca at pca.it (Luca Capello) Date: Mon, 19 Sep 2011 20:33:13 +0200 Subject: [PATCH] Remove the environment file when quitting. Message-ID: <1316457193-26043-1-git-send-email-luca@pca.it> Please see Debian bug #642021 for more information: http://bugs.debian.org/642021 --- Hi there! Please Cc: me, I am not subscribed to the list. The discussion started on the Debian BTS (bug #642021) and it has effects on other part of the Xsession (see bug #642012). Please note that there are two different bugs in Debian: one upstream (the one suggested by the title of bug #642021, with implication for ssh-agent) and another one Debian-specific. The patch included below deals with the former. If needed, the license is the same as GnuPG-2, i.e. GPL-3+. The patch has been tested on my up-to-date Debian sid, both in the console (gpg-agent killed with `kill -s SIGTERM $PID`) and in X11 via XDM login, thus with gpg-agent started by Xsession as it is the default on Debian (gpg-agent killed automatically when quitting X11). In both cases the environment file is deleted. The package I used to test it is available at: Please excuse me if there are fundamental errors, I have very few experience in programming. Thx, bye, Gismo / Luca agent/ChangeLog | 8 ++++++++ agent/gpg-agent.c | 10 +++++++++- 2 files changed, 17 insertions(+), 1 deletions(-) diff --git a/agent/ChangeLog b/agent/ChangeLog index 3c52e1f..9c16e2e 100644 --- a/agent/ChangeLog +++ b/agent/ChangeLog @@ -1,3 +1,11 @@ +2011-09-19 Luca Capello + + * gpg-agent.c: New global *env_file_name variable. + (cleanup): Delete the above file. + (main): Remove local *env_file_name variable. + (main): Do not let cleanup() remove the above file. + (check_own_socket_thread): Ditto. + 2011-09-12 Ben Kibbey * genkey.c (agent_ask_new_passphrase): Allow for an empty passphrase diff --git a/agent/gpg-agent.c b/agent/gpg-agent.c index 0616875..81d9cd4 100644 --- a/agent/gpg-agent.c +++ b/agent/gpg-agent.c @@ -239,6 +239,9 @@ static char *socket_name; /* Name of the communication socket used for ssh-agent-emulation. */ static char *socket_name_ssh; +/* The file containing the environment variables. */ +static char *env_file_name = NULL; + /* We need to keep track of the server's nonces (these are dummies for POSIX systems). */ static assuan_sock_nonce_t socket_nonce; @@ -459,6 +462,7 @@ cleanup (void) deinitialize_module_cache (); remove_socket (socket_name); remove_socket (socket_name_ssh); + remove (env_file_name); } @@ -585,7 +589,6 @@ main (int argc, char **argv ) int debug_wait = 0; int gpgconf_list = 0; gpg_error_t err; - const char *env_file_name = NULL; struct assuan_malloc_hooks malloc_hooks; /* Before we do anything else we save the list of currently open @@ -1140,6 +1143,8 @@ main (int argc, char **argv ) es_putc ('\n', fp); } es_fclose (fp); + + *env_file_name = 0; /* Don't let cleanup() remove the file */ } } @@ -2188,6 +2193,9 @@ check_own_socket_thread (void *arg) *socket_name = 0; if (socket_name_ssh) *socket_name_ssh = 0; + /* Ditto for the file containing the environment variables. */ + if (env_file_name) + *env_file_name = 0; shutdown_pending = 2; log_info ("this process is useless - shutting down\n"); } -- 1.7.6.3 From wk at gnupg.org Mon Sep 26 14:32:28 2011 From: wk at gnupg.org (Werner Koch) Date: Mon, 26 Sep 2011 14:32:28 +0200 Subject: [PATCH] Remove the environment file when quitting. In-Reply-To: <1316457193-26043-1-git-send-email-luca@pca.it> (Luca Capello's message of "Mon, 19 Sep 2011 20:33:13 +0200") References: <1316457193-26043-1-git-send-email-luca@pca.it> Message-ID: <87litblc0z.fsf@vigenere.g10code.de> Hi, instead of using the environment file it is suggested to make use of a feature introduced with 2.0.16: * If the agent's --use-standard-socket option is active, all tools try to start and daemonize the agent on the fly. In the past this was only supported on W32; on non-W32 systems the new configure option --enable-standard-socket may now be used to use this feature by default. Except for some kins of remotely mounted home directories this is a far better system than what we did in the past. What's left to do is if [ "$PS1" ]; then unset GPG_AGENT_INFO unset SSH_AGENT_PID export SSH_AUTH_SOCK="${HOME}/.gnupg/S.gpg-agent.ssh" fi in .bashrc. The first unset is to get rid of any setting of that envvar and the ssh stuff is required because ssh does not know about the on-demand agent starting. Before you may use the gpg-agent for ssh you need to use gpg or gpgsm at least once or run "gpg-connect-agent /bye" once. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From luca at pca.it Tue Sep 27 10:50:00 2011 From: luca at pca.it (Luca Capello) Date: Tue, 27 Sep 2011 10:50:00 +0200 Subject: [PATCH] Remove the environment file when quitting. In-Reply-To: <87litblc0z.fsf@vigenere.g10code.de> (Werner Koch's message of "Mon, 26 Sep 2011 14:32:28 +0200") References: <1316457193-26043-1-git-send-email-luca@pca.it> <87litblc0z.fsf@vigenere.g10code.de> Message-ID: <874nzy8j47.fsf@gismo.pca.it> Hi there! Cc:ing the Debian bug, please keep it in the loop. On Mon, 26 Sep 2011 14:32:28 +0200, Werner Koch wrote: > instead of using the environment file it is suggested to make use of a > feature introduced with 2.0.16: > > * If the agent's --use-standard-socket option is active, all tools > try to start and daemonize the agent on the fly. In the past this > was only supported on W32; on non-W32 systems the new configure > option --enable-standard-socket may now be used to use this feature > by default. > > Except for some kins of remotely mounted home directories this is a far > better system than what we did in the past. I see three problems with this approach. 1) remotely-mounted home directories could be a problem if their filesystems do not support fifos or sockets. And Debian cares about NFS-mounted home directories: I am not speaking for the Debian maintainer, but if the easiest (only?) solution is to use the environment variables, then we should use that. 2) gpg-agent's manpage still thinks that using GPG_AGENT_INFO is the first choice and *then* falling back to the standard socket: By enabling this option @command{gpg-agent} will listen on the socket named @file{S.gpg-agent}, located in the home directory, and not create a random socket below a temporary directory. Tools connecting to @command{gpg-agent} should first try to connect to the socket given in environment variable @var{GPG_AGENT_INFO} and then fall back to this socket. This option may not be used if the home directory is mounted on a remote file system which does not support special files like fifos or sockets. 3) Debian gpg-agent_2.0.18 is compiled without --enable-standard-socket, but this is easily fixable ;-) > What's left to do is > > if [ "$PS1" ]; then I would say that we should also check if the agent is running: if [ "$PS1" ] && gpg-agent 2>/dev/null; then > unset GPG_AGENT_INFO > unset SSH_AGENT_PID > export SSH_AUTH_SOCK="${HOME}/.gnupg/S.gpg-agent.ssh" > fi > > in .bashrc. The first unset is to get rid of any setting of that envvar > and the ssh stuff is required because ssh does not know about the > on-demand agent starting. Unfortunately, I had already discovered the latter: Going back to the subject: what is the reason for the environment file not being deleted when quitting? As I wrote in my first email, I have very few experience in programming and thus I can be wrong, but I still fail to see why ATM only the sockets are deleted. If there is no socket gpg-agent is not running, thus keeping the now-useless environment variables somewhere does not seem right to me. Thx, bye, Gismo / Luca -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From wk at gnupg.org Wed Sep 28 16:20:21 2011 From: wk at gnupg.org (Werner Koch) Date: Wed, 28 Sep 2011 16:20:21 +0200 Subject: [PATCH] Remove the environment file when quitting. In-Reply-To: <874nzy8j47.fsf@gismo.pca.it> (Luca Capello's message of "Tue, 27 Sep 2011 10:50:00 +0200") References: <1316457193-26043-1-git-send-email-luca@pca.it> <87litblc0z.fsf@vigenere.g10code.de> <874nzy8j47.fsf@gismo.pca.it> Message-ID: <8739fgkau2.fsf@vigenere.g10code.de> On Tue, 27 Sep 2011 10:50, luca at pca.it said: > 1) remotely-mounted home directories could be a problem if their > filesystems do not support fifos or sockets. And Debian cares about > NFS-mounted home directories: Right. However the majority of users don't have NFS mounted home directories and those who have do have an admin to ask what to do. gpg-agent provides an option to revert back to the old behaviour/ > 2) gpg-agent's manpage still thinks that using GPG_AGENT_INFO is the > first choice and *then* falling back to the standard socket: Quite possible. Our development resources are limited and updates to the documentation of the stable release is unfortunately not a primary target. > 3) Debian gpg-agent_2.0.18 is compiled without --enable-standard-socket, > but this is easily fixable ;-) That might be a good thing to do. It would give us some feedback. > I would say that we should also check if the agent is running: > > if [ "$PS1" ] && gpg-agent 2>/dev/null; then There is no need for it. Really. If you want the agent for ssh, you may simply start it in the interactive shell gpg-connect-agent /bye it does nothing if the agent is already running. > Going back to the subject: what is the reason for the environment file > not being deleted when quitting? As I wrote in my first email, I have You can't delete the environment variables either. Deleting the file may also exhibit a race if at the same time another agent is started. Note also that gpg-agent terminates itself if it detects another running instance or a started child process has terminated. > fail to see why ATM only the sockets are deleted. If there is no socket > gpg-agent is not running, thus keeping the now-useless environment > variables somewhere does not seem right to me. You can't remove environment variables of another process. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.