From gniibe at fsij.org Thu May 1 05:09:29 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 01 May 2014 12:09:29 +0900 Subject: [PATCH] 1.4.x: Fix PC/SC Message-ID: <1398913769.3081.7.camel@cfw2.gniibe.org> Hello, For the issue 1358, I fixed 2.0 (and master branch) but not 1.4. https://bugs.g10code.com/gnupg/issue1358 I thought MacOS X user used 2.0 or internal driver, but it seems wrong. Here is a patch to 1.4, backported. Building on x86 has no problem. OK to apply? diff --git a/g10/apdu.c b/g10/apdu.c index 4544d70..62180b3 100644 --- a/g10/apdu.c +++ b/g10/apdu.c @@ -83,6 +83,11 @@ #define DLSTDCALL #endif +#if defined(__APPLE__) || defined(_WIN32) || defined(__CYGWIN__) +typedef unsigned int pcsc_dword_t; +#else +typedef unsigned long pcsc_dword_t; +#endif /* Helper to pass parameters related to keypad based operations. */ struct pininfo_s @@ -116,9 +121,9 @@ struct reader_table_s { ccid_driver_t handle; } ccid; struct { - unsigned long context; - unsigned long card; - unsigned long protocol; + long context; + long card; + pcsc_dword_t protocol; #ifdef NEED_PCSC_WRAPPER int req_fd; int rsp_fd; @@ -225,69 +230,76 @@ static char (* DLSTDCALL CT_close) (unsigned short ctn); it. */ #define PCSC_ERR_MASK(a) ((a) & 0xffffffff) - struct pcsc_io_request_s { - unsigned long protocol; - unsigned long pci_len; + pcsc_dword_t protocol; + pcsc_dword_t pci_len; }; typedef struct pcsc_io_request_s *pcsc_io_request_t; +#ifdef __APPLE__ +#pragma pack(1) +#endif + struct pcsc_readerstate_s { const char *reader; void *user_data; - unsigned long current_state; - unsigned long event_state; - unsigned long atrlen; + pcsc_dword_t current_state; + pcsc_dword_t event_state; + pcsc_dword_t atrlen; unsigned char atr[33]; }; +#ifdef __APPLE__ +#pragma pack() +#endif + typedef struct pcsc_readerstate_s *pcsc_readerstate_t; -long (* DLSTDCALL pcsc_establish_context) (unsigned long scope, +long (* DLSTDCALL pcsc_establish_context) (pcsc_dword_t scope, const void *reserved1, const void *reserved2, - unsigned long *r_context); -long (* DLSTDCALL pcsc_release_context) (unsigned long context); -long (* DLSTDCALL pcsc_list_readers) (unsigned long context, + long *r_context); +long (* DLSTDCALL pcsc_release_context) (long context); +long (* DLSTDCALL pcsc_list_readers) (long context, const char *groups, - char *readers, unsigned long*readerslen); -long (* DLSTDCALL pcsc_get_status_change) (unsigned long context, - unsigned long timeout, + char *readers, pcsc_dword_t *readerslen); +long (* DLSTDCALL pcsc_get_status_change) (long context, + pcsc_dword_t timeout, pcsc_readerstate_t readerstates, - unsigned long nreaderstates); -long (* DLSTDCALL pcsc_connect) (unsigned long context, + pcsc_dword_t nreaderstates); +long (* DLSTDCALL pcsc_connect) (long context, const char *reader, - unsigned long share_mode, - unsigned long preferred_protocols, - unsigned long *r_card, - unsigned long *r_active_protocol); -long (* DLSTDCALL pcsc_reconnect) (unsigned long card, - unsigned long share_mode, - unsigned long preferred_protocols, - unsigned long initialization, - unsigned long *r_active_protocol); -long (* DLSTDCALL pcsc_disconnect) (unsigned long card, - unsigned long disposition); -long (* DLSTDCALL pcsc_status) (unsigned long card, - char *reader, unsigned long *readerlen, - unsigned long *r_state, - unsigned long *r_protocol, - unsigned char *atr, unsigned long *atrlen); -long (* DLSTDCALL pcsc_begin_transaction) (unsigned long card); -long (* DLSTDCALL pcsc_end_transaction) (unsigned long card, - unsigned long disposition); -long (* DLSTDCALL pcsc_transmit) (unsigned long card, + pcsc_dword_t share_mode, + pcsc_dword_t preferred_protocols, + long *r_card, + pcsc_dword_t *r_active_protocol); +long (* DLSTDCALL pcsc_reconnect) (long card, + pcsc_dword_t share_mode, + pcsc_dword_t preferred_protocols, + pcsc_dword_t initialization, + pcsc_dword_t *r_active_protocol); +long (* DLSTDCALL pcsc_disconnect) (long card, + pcsc_dword_t disposition); +long (* DLSTDCALL pcsc_status) (long card, + char *reader, pcsc_dword_t *readerlen, + pcsc_dword_t *r_state, + pcsc_dword_t *r_protocol, + unsigned char *atr, pcsc_dword_t *atrlen); +long (* DLSTDCALL pcsc_begin_transaction) (long card); +long (* DLSTDCALL pcsc_end_transaction) (long card, + pcsc_dword_t disposition); +long (* DLSTDCALL pcsc_transmit) (long card, const pcsc_io_request_t send_pci, const unsigned char *send_buffer, - unsigned long send_len, + pcsc_dword_t send_len, pcsc_io_request_t recv_pci, unsigned char *recv_buffer, - unsigned long *recv_len); -long (* DLSTDCALL pcsc_set_timeout) (unsigned long context, - unsigned long timeout); + pcsc_dword_t *recv_len); +long (* DLSTDCALL pcsc_set_timeout) (long context, + pcsc_dword_t timeout); /* Prototypes. */ @@ -990,7 +1002,7 @@ pcsc_send_apdu_direct (int slot, unsigned char *apdu, size_t apdulen, { long err; struct pcsc_io_request_s send_pci; - unsigned long recv_len; + pcsc_dword_t recv_len; if (!reader_table[slot].atrlen && (err = reset_pcsc_reader (slot))) @@ -1276,8 +1288,8 @@ connect_pcsc_card (int slot) else { char reader[250]; - unsigned long readerlen, atrlen; - unsigned long card_state, card_protocol; + pcsc_dword_t readerlen, atrlen; + pcsc_dword_t card_state, card_protocol; atrlen = DIM (reader_table[0].atr); readerlen = sizeof reader -1 ; @@ -1286,8 +1298,8 @@ connect_pcsc_card (int slot) &card_state, &card_protocol, reader_table[slot].atr, &atrlen); if (err) - log_error ("pcsc_status failed: %s (0x%lx) %lu\n", - pcsc_error_string (err), err, readerlen); + log_error ("pcsc_status failed: %s (0x%lx) %u\n", + pcsc_error_string (err), err, (unsigned int)readerlen); else { if (atrlen > DIM (reader_table[0].atr)) @@ -1473,7 +1485,7 @@ open_pcsc_reader_direct (const char *portstr) long err; int slot; char *list = NULL; - unsigned long nreader; + pcsc_dword_t nreader; char *p; slot = new_reader_slot (); -- From suraj.krishnaswami at gmail.com Fri May 2 07:15:19 2014 From: suraj.krishnaswami at gmail.com (suraj krishnaswami) Date: Fri, 2 May 2014 10:45:19 +0530 Subject: Changing the name of "libgpg-error" shared library. Message-ID: Hi, I am currently using the library "libgpg-error", i am able to compile the code using, mingw for windows. I want to change the name of the output file, from "libgpg-error-0" to suppose "libgpg-error", can you please help me, for how to do it. I am new to using scripts, i am finding it very difficult to understand the scripts. Waiting for a reply. Thanks And Regard, Suraj K. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lrn1986 at gmail.com Sat May 3 01:49:19 2014 From: lrn1986 at gmail.com (LRN) Date: Sat, 03 May 2014 03:49:19 +0400 Subject: Strange sizeofs Message-ID: <53642EFF.9030903@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 gen-w32-lock-obj in libgpg-error generates code that looks like this: > sizeof CRITICAL_SECTION = 24 What is that supposed to mean? Is this some kind of MSVC feature that i don't know of? - -- O< ascii ribbon - stop html email! - www.asciiribbon.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQEcBAEBAgAGBQJTZC7/AAoJEOs4Jb6SI2CwcagH+gMXFp/6w66fHoXasP8VbRnX HAJTiXG9Vdo7wYhokPDaLPynqU6QdXxFoIoZt9hyBcZ2bn1tIhpfyfjOaYSfwaKP jPDo6RJS7y0C8DmbUGG0i3qFLXsd9BCZ1ZQjuWxhsjxO57diLowyYoeFfRujA2yW DGPLxtY4UiZ8d26+u7baZspG6iJmc0tW9dN7vk+pNbXp6wi8Rzc6xihqVAF6e39B 4JB88lDWoxwW2+DAQNm7a2Zx2aijVotaPJyUDh5lWMFIIj1KPDtAT9EfZ1F6ITE5 sa4E+Haq22lALjgoYNhv5J32vM6ce//rwtIIfcTQfkeAlEsPeI7WTH50KuROHd4= =jShk -----END PGP SIGNATURE----- From wk at gnupg.org Sat May 3 12:24:59 2014 From: wk at gnupg.org (Werner Koch) Date: Sat, 03 May 2014 12:24:59 +0200 Subject: Strange sizeofs In-Reply-To: <53642EFF.9030903@gmail.com> (LRN's message of "Sat, 03 May 2014 03:49:19 +0400") References: <53642EFF.9030903@gmail.com> Message-ID: <87d2fvcg78.fsf@vigenere.g10code.de> On Sat, 3 May 2014 01:49, lrn1986 at gmail.com said: > gen-w32-lock-obj in libgpg-error generates code that looks like this: >> sizeof CRITICAL_SECTION = 24 > What is that supposed to mean? Is this some kind of MSVC feature that i don't > know of? printf ("sizeof CRITICAL_SECTION = %u\n", (int)sizeof (CRITICAL_SECTION)); printf ("sizeof _gpgrt_lock_t = %u\n", (int)sizeof lk); is easy to read code to print the size of a CRITICAL_SECTION. And no, we don't support building nativly on Window. src/syscfg/lock-obj-pub.mingw32.h is the actual file I created manually with the help of that little helper. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue May 6 15:16:08 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 06 May 2014 15:16:08 +0200 Subject: Changing the name of "libgpg-error" shared library. In-Reply-To: (suraj krishnaswami's message of "Fri, 2 May 2014 10:45:19 +0530") References: Message-ID: <87d2fr82uf.fsf@vigenere.g10code.de> On Fri, 2 May 2014 07:15, suraj.krishnaswami at gmail.com said: > I am currently using the library "libgpg-error", i am able to compile the > code using, mingw for windows. I want to change the name of the output Note that this is not a supported way of building libgpg-error. A POSIX system with a cross compiler toolchain is required. > file, from "libgpg-error-0" to suppose "libgpg-error", can you please help > me, for how to do it. Please don't do that. Having the ABI version number in the DLL name is important. Without that it will be impossible to change the ABI. The SO number is set by libtool, which is a tool build during the configure run from build-aux/ltmain.sh. Libtool is called by the automake Makefile directive: libgpg_error_la_LDFLAGS = -version-info \ @LIBGPG_ERROR_LT_CURRENT@:@LIBGPG_ERROR_LT_REVISION@:@LIBGPG_ERROR_LT_AGE@ \ $(no_undefined) $(export_symbols) which tells libtool the 3-part SO version info out of which it generates a SO number for the specific platform. That is done deep in the guts of libtool: elif test -n "$soname_spec"; then # bleh windows case $host in x86_64-*mingw32*) func_arith $current - $age major=$func_arith_result versuffix="6-$major" ;; *cygwin* | mingw* | *cegcc*) func_arith $current - $age major=$func_arith_result versuffix="-$major" ;; esac As you can see, for 64 bit Windows, libtool also adds a "6" to the basename of the DLL. That is a GnuPG tool related hack and might not be available in other libtool versions. However, you are not supposed to change that. > I am new to using scripts, i am finding it very difficult to understand the > scripts. Right, libtool is quite complicated. For serious hacking of this software a thorough understanding of Bourne shell scripts and the Unix system is highly suggested. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Tue May 6 16:33:00 2014 From: wk at gnupg.org (Werner Koch) Date: Tue, 06 May 2014 16:33:00 +0200 Subject: Dirmngr now supports hkps In-Reply-To: <5368A688.60005@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Tue, 06 May 2014 11:08:24 +0200") References: <5368A688.60005@sumptuouscapital.com> Message-ID: <878uqf7zab.fsf@vigenere.g10code.de> Hi, Kristian announced at gnupg-users that SKS 1.15 has been released. I take this opportunity to tell that I pushed changes to GnuPG master which gives us hpks again. Those who follow master may want to test these changes. They require that GnuTLS 3.x is installed. In master (i.e. GnuPG 2.1) the keyserver helper programs are gone and have been replaced by the dirmngr daemon. This has the advantage that we can keep a state and for example detect non-answering servers from a pool. Dirmngr is started on the fly, thus there is not much configuration required. However, for TLS a basic configuration is required in ~/.gnupg/dirmngr.conf: --8<---------------cut here---------------start------------->8--- verbose debug 1024 hkp-cacert /home/foo/.gnupg/sks-keyservers.netCA.pem --8<---------------cut here---------------end--------------->8--- "verbose" and "debug 1024" are not actually needed but are useful for testing. The given certificate is in the GIT repo and should work for the servers in the hkps.pool. Gpg's keyserver-option "check-cert" and "ca-cert-file" have no more function. Dirmngr's --hkp-cacert option(s) must be used instead. The actual keyserver to be used is still configured in gpg.conf so that Dirmngr may use different keyservers depending on gpg's configuration. Here is now you can use gpg-connect-agent for a quick test $ gpg-connect-agent --dirmngr 'keyserver hkps://sks.alpha-labs.net' 'ks_get 1e42b367' /bye OK S PROGRESS tick ? 0 0 S SOURCE https://sks.alpha-labs.net:443 D -----BEGIN PGP PUBLIC KEY BLOCK-----%0A D Version: SKS 1.1.4%0A D Comment: Hostname: sks.alpha-labs.net%0A D %0A D mQMqBEd5F8MRCACfArHCJFR6nkmxNiW+UE4PAW3bQla9JWFqCwu4VqLkPI/lHb5pxHff8Fzy%0A D 2O89BxD/6hXSDx2SlVmAGHOCJhShx1vfNGVYNsJn2oNK50in9kGvD0+mVACfy5MyPV8mtMcO%0A [...] D -----END PGP PUBLIC KEY BLOCK-----%0D%0A OK (note that the "D" lines are percent escaped). That is basically the same what gpg does with the usual: $ gpg2 --keyserver hkps://sks.alpha-labs.net --recv-key 1e42b367 gpg: NOTE: THIS IS A DEVELOPMENT VERSION! gpg: It is only intended for test purposes and should NOT be gpg: used in a production environment or with production keys! gpg: key 1E42B367: "Werner Koch " not changed gpg: Total number processed: 1 gpg: unchanged: 1 Other interesting stuff might be: $ gpg-connect-agent --dirmngr > HELP keyserver # KEYSERVER [] [|] # Options are: # --help # --clear Remove all configured keyservers # --resolve Resolve HKP host names and rotate # --hosttable Print table of known hosts and pools # --dead Mark as dead # --alive Mark as alive # # If called without arguments list all configured keyserver URLs. # If called with an URI add this as keyserver. Note that keyservers # are configured on a per-session base. A default keyserver may already be # present, thus the "--clear" option must be used to get full control. # If "--clear" and an URI are used together the clear command is # obviously executed first. A RESET command does not change the list # of configured keyservers. OK > keyserver --hosttable S # hosttable (idx, ipv4, ipv6, dead, name, time): S # 0 4 sks.alpha-labs.net OK > keyserver hkps://hkps.pool.sks-keyservers.net OK > keyserver --resolve --hosttable S PROGRESS tick ? 0 0 S PROGRESS tick ? 0 0 S PROGRESS tick ? 0 0 S # https://services.spodhuis.org:443 S # hosttable (idx, ipv4, ipv6, dead, name, time): S # 0 4 sks.alpha-labs.net S # 1 hkps.pool.sks-keyservers.net S # . --> 5 8 9 2 7 6 4 10 3 11* 12 S # 2 4 alita.karotte.org S # 3 4 pax.skoopsmedia.net S # 4 4 mimir.alderwick.co.uk S # 5 4 216.66.15.2 S # 6 4 dainn.alderwick.co.uk S # 7 4 astrath.net S # 8 4 79.143.214.216 S # 9 4 89-68-150-88.dynamic.chello.pl S # 10 4 mx1.adeti.org S # 11 4 services.spodhuis.org S # 12 6 sks.spodhuis.org OK Note that the --resolve option does not only resolve the pool but also switches to a new server from the alive servers. A host is marked dead after 3 tries and resurrected after 3 hours (unless manually marked dead). Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kristian.fiskerstrand at sumptuouscapital.com Tue May 6 19:45:46 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Tue, 06 May 2014 19:45:46 +0200 Subject: Dirmngr now supports hkps In-Reply-To: <878uqf7zab.fsf@vigenere.g10code.de> References: <5368A688.60005@sumptuouscapital.com> <878uqf7zab.fsf@vigenere.g10code.de> Message-ID: <53691FCA.4070207@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/06/2014 04:33 PM, Werner Koch wrote: > Hi, > > Kristian announced at gnupg-users that SKS 1.15 has been released. > I take this opportunity to tell that I pushed changes to GnuPG > master which gives us hpks again. Those who follow master may want > to test these changes. They require that GnuTLS 3.x is installed. Thats great, I'll look into it for sure :) One thing I noticed is that since commit 8412a5825c225c8ff14de3ffaad2e55e040b2eca `make -j4` fails on my computer with ERROR described below. As of 84289e85c72ae58c321dfdb96816700a6b7f7122 this is working. Forcing -j1 allows building after this commit. Also, if using --program-prefix='gpg2.1-' gpg fails to locate the dirmngr, gpg: failed to start the dirmngr '/usr/bin/dirmngr': No such file or directory creating a symlink for dirmngr (and for good measure dirmngr-client) fixes this issue. Out of curiosity (as I haven't had time to look deeply enough into the source code yet), how does dirmngr handle SNI in the case of the hkps pool being resolved to multiple client? Does it still present itself as SNI=hkps.pool.sks-keyservers.net when contacting individual servers? Otherwise (if the direct hostname is used) we might have instances where the per-keyserver certificate is presented in such cases. ## ERROR ## ssing-field-initializers -Wdeclaration-after-statement - -Wno-pointer-sign -Wpoint er-arith -Wno-psabi -c -o t_http-t-http.o `test -f 't-http.c' || echo './'`t-htt p.c make[3]: *** No rule to make target `../common/libcommontls.a', needed by `t-http'. Stop. make[3]: *** Waiting for unfinished jobs.... make[3]: Leaving directory `/var/tmp/portage/app-crypt/gnupg-9999/work/gnupg-9999/common' make[2]: *** [all] Error 2 - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Nulla regula sine exceptione No rule without exception -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTaR/HAAoJEPw7F94F4TagZ9EP/0jXbmb6Z4EZLgjs5BqBifXx FzC5eR7dwdeY4LqNAEfw56R6ndyY8I20u4STgdsZ2oiOsFpjCwrzq0E80TtE/MLY 0eOS4v0e6A5Ix6wujhOhXxh9l7p8Y0ySn6WIP/VqILHfsUe4seqTvB1k2rljwTXY JmBk+EsfPjA/1sfk7SdKrjuZhNK5GsRtWT/KoFwgX0rbzH8fIMQLzOUoJ7PJ70hk 8F6hv0/ALh9QVBnpJO1aN/1JAgY+gVml0wMXqKxUReGUfiwDT9iy4PGpFTk7kAGR mUxu/H3jxvOUBhk/ROFvUMe164K55YMWceSZYBEqEfXfnHC1Y9MS4mOI2TkzFHg3 flXPFgAoIfD//oZG9sOhSVo1duG08IkCTWe1wzaZF/PA+15oEMWOd2Oyh62cL8ei WABl8nqyzgPcamAPU/40VnyFa2DqdheJiBsrjdKtVO1AjtkfzwtmME/3XdQE9Opo st4wvTqJd+WbU8gNgPGI9ENqMw6iBMg9YxvrkjfZGO+3UCCBXVWBaH3h8liZtCRW dwcjNFHaltIGgK41wBIuXWfZizzKljsmnYX0YrzCNxRZEQQodFqCH1dCaSUyStOe bMr9CUelQeCLEcfIP+A5QTv1n4VuwuIxmdbXM6zhz+aZUT8XjVFfqMOHtSUMjoaf VL1EBZ3sIH630TSRbW8F =UeD3 -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Tue May 6 11:05:05 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 06 May 2014 05:05:05 -0400 Subject: forcing "--compress-algo Uncompressed" in gpgme Message-ID: <87d2frwa4e.fsf@alice.fifthhorseman.net> Hi GnuPG folks-- I'm using gpgme, and i'd like to pass "--compress-algo Uncompressed" to the invoked gpg instance (this will be used programmatically in a way that i want to avoid CRIME-style attacks). It's not clear to me from reading gpgme.h how i would include that directive. i see no reference to anything including the word "compress" in gpgme.h, and while there are enums covering encryption and digest algorithms, i don't see matching enums for compression. Is there a way to do this that i'm missing? or does gpgme need to be extended to make this work? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From kristian.fiskerstrand at sumptuouscapital.com Wed May 7 12:24:15 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 07 May 2014 12:24:15 +0200 Subject: SSH-agent / OpenPGP auth subkey issues Message-ID: <536A09CF.9050004@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, I haven't had time to debug this issue properly, but I seem to have issues with ssh-agent while using an OpenPGP auth subkey starting with gnupg commit 072432883ededa15bf35f80102e0572746ba4af1 (i.e. last working is a77ed0f266d03e234027dda4de5a7f3dd6787b1e ) #not working 072432883ededa15bf35f80102e0572746ba4af1# $ ssh-add -l The agent has no identities. $ gpg2.1 --version gpg (GnuPG) 2.1.0-beta369 libgcrypt 1.7.0-beta60 #working a77ed0f266d03e234027dda4de5a7f3dd6787b1e# $ ssh-add -l 4096 93:a1:54:1d:c0:89:ea:6a:8d:90:6e:8d:29:bb:e1:01 (none) (RSA) $ gpg2.1 --version gpg (GnuPG) 2.1.0-beta368 libgcrypt 1.7.0-beta60 - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "History doesn't repeat itself, but it does rhyme." (Mark Twain) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTagnLAAoJEPw7F94F4TagU5sP/RexQ8QN6gCRXq9fOsr1seKM lD2pie98+AzH/VXNg3S8BZpigc1VYTQLt3t1pL+k1ceB5oWkTvnMnCTY0gN+b4ue AGrOBi/9TkVfsHS+E+SpsEGJnXGJ1b5qH6KkgK6MJ29rAraIRJwEvRw0v54APbwM qlKdAUmNGpmjuQJQnUjKl4yyahC3gQM4HH3vWLiAgMtawOvdcFPlZRDoydH7zgXW i2vWwG5vZ3UrmzYxdMNo+tZ9DaCUn1SQCNZQdKqf+pcpT1XyLcARakt7YTFupWdG s6+LRyIXr5HjhsU6p6pDfk4DEt7r6uQsgrTK0jK7QwWDPeS/pe/YwLmpQWW9cBDi IfCeSS9krXfDgLAQyo5wGng/B2BG9CMBM87C7MGpk8mW0hChi/Kmhv+r2HnNkXZl CqLinQJZ7W8Gmk/0+jdb92e5/JKSr89KcctdKK5YyCIQORzrVHd4J7c3uzrk9u0j gKAzjP8Ivutp94b7k77KyLGAf57DlyqHwB8belU4HhMaOP0fFGvf7IKFvHGWi0Kg i7WvtkT0Qq+75JBIzklO/RHpJTij7IVuL+g06A/uNAEBGhNpLzeEsEYKziPGN7VB Cvd1FN2TMc7PXzsICpnSmdBtqnLDZw3bEWBJRstjaJcaXqNg8EeDQzsIaWRll7TJ ihBbXOINRTKeuHKJ+EVV =XmeW -----END PGP SIGNATURE----- From gniibe at fsij.org Wed May 7 15:06:10 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Wed, 07 May 2014 22:06:10 +0900 Subject: SSH-agent / OpenPGP auth subkey issues In-Reply-To: <536A09CF.9050004@sumptuouscapital.com> References: <536A09CF.9050004@sumptuouscapital.com> Message-ID: <1399467970.6312.0.camel@latx1.gniibe.org> On 2014-05-07 at 12:24 +0200, Kristian Fiskerstrand wrote: > #not working 072432883ededa15bf35f80102e0572746ba4af1# > $ ssh-add -l > The agent has no identities. Reading the change of 072432883ededa15bf35f80102e0572746ba4af1, it might be comment handling problem. Here is a possible fix. Sorry, I don't test it (my auth keys are in my tokens). diff --git a/agent/command-ssh.c b/agent/command-ssh.c index a814681..d619324 100644 --- a/agent/command-ssh.c +++ b/agent/command-ssh.c @@ -2331,7 +2331,9 @@ ssh_send_key_public (estream_t stream, gcry_sexp_t key, else { err = ssh_key_extract_comment (key, &comment); - if (!err) + if (err) + err = stream_write_cstring (stream, "(none)"); + else err = stream_write_cstring (stream, comment); } if (err) -- From kristian.fiskerstrand at sumptuouscapital.com Wed May 7 15:19:39 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 07 May 2014 15:19:39 +0200 Subject: SSH-agent / OpenPGP auth subkey issues In-Reply-To: <1399467970.6312.0.camel@latx1.gniibe.org> References: <536A09CF.9050004@sumptuouscapital.com> <1399467970.6312.0.camel@latx1.gniibe.org> Message-ID: <536A32EB.7090308@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/07/2014 03:06 PM, NIIBE Yutaka wrote: > On 2014-05-07 at 12:24 +0200, Kristian Fiskerstrand wrote: >> #not working 072432883ededa15bf35f80102e0572746ba4af1# $ ssh-add >> -l The agent has no identities. > > Reading the change of 072432883ededa15bf35f80102e0572746ba4af1, it > might be comment handling problem. > > Here is a possible fix. Sorry, I don't test it (my auth keys are > in my tokens). Thanks Niibe, I can confirm that this patch gets my system back in working order when applied on top of current tip. $ ssh-add -l 4096 93:a1:54:1d:c0:89:ea:6a:8d:90:6e:8d:29:bb:e1:01 (none) (RSA) $ gpg2.1 --version gpg (GnuPG) 2.1.0-beta413 - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "Statistics are like a bikini. What they reveal is suggestive, but what they conceal is vital." (Aaron Levenstein) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTajLoAAoJEPw7F94F4TagAEIQAIdHHQh26TIkRIBlrSGFd1nE RRoRIEqtkmAo5/juVWHR1aeMZWbh6LOHgm/LxTRNxREu8cMc0Mb54KHvVJLyvdqS iab4OtaZGPYMrX88HRkyPIXgxZwSnMNlU88Q1ccaEOGLC9dvM7ZJlVm8FdhvhdcU 0oyogM88vHpy/OMidHGAHRqhQMkJviYxZrsdUYA9nE9RiWiXUGQ5e5xiujl2/hOg ypKju3NkUmR5CNCdZ4R8AS2M5A/MaYUbeQiu57RtQ4Nw5Syxec/AesZfcTTZ92dG Dg+cayxponjNW4NWb785SVzlGMkqhet4E5PY/AILzacZt31Pbh8YVwk1rMyVysnw 81ag0LOz/X/RNa2aYaW48vQ9gQwEt87WOMXIyfreYRfg0Izry5FeAqfT+ePNSi6Y PmdC5IX1Ol9RFdhKV08KOuBDQhxbprahIutA+IlkwTrRMTAvT6DoYlaqOdG43aZe fF5urHnF3Fce2R+Qjp2e1kzsa92sD1BhtaRdD8BHnMo8B9QIqsnYWufEESsnHBff +elwVGJzeUtIBSTIRaDR40+7KDu/DZq8QHvUL1nBmyV8huJmt8TKiNV0PCoDAUmA zozrgLoRsba4x5BjWaZ0EUe/6dIIPwrt1A/0nYJBcTyKLRatQeetSoZCde/0KgXk u9+dQ6JZSnqBjMhe3Bfx =6l+B -----END PGP SIGNATURE----- From wk at gnupg.org Wed May 7 15:33:06 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 May 2014 15:33:06 +0200 Subject: forcing "--compress-algo Uncompressed" in gpgme In-Reply-To: <87d2frwa4e.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 06 May 2014 05:05:05 -0400") References: <87d2frwa4e.fsf@alice.fifthhorseman.net> Message-ID: <87oaz967e5.fsf@vigenere.g10code.de> On Tue, 6 May 2014 11:05, dkg at fifthhorseman.net said: > Is there a way to do this that i'm missing? or does gpgme need to be > extended to make this work? Needs to be extended. Or put put it into gpg.conf. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed May 7 15:32:14 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 May 2014 15:32:14 +0200 Subject: SSH-agent / OpenPGP auth subkey issues In-Reply-To: <536A09CF.9050004@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Wed, 07 May 2014 12:24:15 +0200") References: <536A09CF.9050004@sumptuouscapital.com> Message-ID: <87siol67fl.fsf@vigenere.g10code.de> On Wed, 7 May 2014 12:24, kristian.fiskerstrand at sumptuouscapital.com said: > I haven't had time to debug this issue properly, but I seem to have > issues with ssh-agent while using an OpenPGP auth subkey starting with Is that the same auth subkey? RSA 4096? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kristian.fiskerstrand at sumptuouscapital.com Wed May 7 15:34:01 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 07 May 2014 15:34:01 +0200 Subject: SSH-agent / OpenPGP auth subkey issues In-Reply-To: <87siol67fl.fsf@vigenere.g10code.de> References: <536A09CF.9050004@sumptuouscapital.com> <87siol67fl.fsf@vigenere.g10code.de> Message-ID: <536A3649.1060203@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/07/2014 03:32 PM, Werner Koch wrote: > On Wed, 7 May 2014 12:24, > kristian.fiskerstrand at sumptuouscapital.com said: >> I haven't had time to debug this issue properly, but I seem to >> have issues with ssh-agent while using an OpenPGP auth subkey >> starting with > > Is that the same auth subkey? RSA 4096? Yes, the patch provided by Niibe fixes the issue. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "In politics stupidity is not a handicap." (Napoleon Bonaparte) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTajZJAAoJEPw7F94F4TagqPsQAJ+snXx2lmfRpR49xQ2mmPnG nNoM6IeBZxd4BFTYW1w5iaS1m7aMHYEmStN8Vl+FN2LciU/qeHqRSt6Q6XhLWRgO i0QhY9pQ99X6fklDhLCuNkz5Lf5IqrlFrEzcFxLr9c+uoC30mOVC5LS+0LRO89DW 1i+MwbssQj66kdym7iU2+iN2FPphM0lIXcbZOnOqmwnWdRADVRiv+dy/YEnV3iwn BnQDqFvj6Aj1v4stq+KRwOjs5tAGFSriRZ9Z7U5burGEMX3kqZa+zLVHMeRGxxd9 XSkciGMt2RQq/8d9R6CQW5u6woPiXn66wVnUp9NILlKIolsBIsn49pBpDYBXNI+6 L/mw70w6g5i5eCxVIsYx/RnCdqTpqNvdTCe/1lPejodCoI/wmgpBIv4Q3uhY791E 8+hEseX+Ht+y2qJ0y8PCM5AacGyahagJvpzBi7//mLYmpZcVYC6GZ+KZwYHS7zYr Tt0yUHJ4EtcuuW3ZKPY1CaJZ0KacJwgYBYHsKqydwasnMceGA/D7HLSaFA+BfSC8 SKy74tIYv+LLCLR6n05vp6ducFOnX27z2HKnbQidBF7zq4ef+sVm48AkKNhKaYh5 NhrsOOGlqh3YZLT9MuNKr/mKc0lpsyo7/ZpAwtjetxhvJgF9tZ+kjKRS3gBiTbkO ImxuaI/IhxosGPKK3aLA =IXP8 -----END PGP SIGNATURE----- From wk at gnupg.org Wed May 7 15:39:08 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 May 2014 15:39:08 +0200 Subject: forcing "--compress-algo Uncompressed" in gpgme In-Reply-To: <87d2frwa4e.fsf@alice.fifthhorseman.net> (Daniel Kahn Gillmor's message of "Tue, 06 May 2014 05:05:05 -0400") References: <87d2frwa4e.fsf@alice.fifthhorseman.net> Message-ID: <87k39x6743.fsf@vigenere.g10code.de> On Tue, 6 May 2014 11:05, dkg at fifthhorseman.net said: > Is there a way to do this that i'm missing? or does gpgme need to be > extended to make this work? For encrypt and encrypt_sign it will be easy to add a flag GPGME_ENCRYPT_NO_COMPRESS = 16 But for a plain sign operation I see no easy way to convey such a flag. OTOH, such a flag is does not see every useful in that case. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed May 7 17:04:51 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 May 2014 17:04:51 +0200 Subject: Dirmngr now supports hkps In-Reply-To: <53691FCA.4070207@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Tue, 06 May 2014 19:45:46 +0200") References: <5368A688.60005@sumptuouscapital.com> <878uqf7zab.fsf@vigenere.g10code.de> <53691FCA.4070207@sumptuouscapital.com> Message-ID: <87bnv96358.fsf@vigenere.g10code.de> On Tue, 6 May 2014 19:45, kristian.fiskerstrand at sumptuouscapital.com said: > 8412a5825c225c8ff14de3ffaad2e55e040b2eca `make -j4` fails on my > computer with ERROR described below. As of Fixed. > Also, if using --program-prefix='gpg2.1-' gpg fails to locate the > dirmngr, Better use --prefix or --exec-prefix to put that version into a different directory. To allow for an arbitrary prefix we need to tell this common/homedir.c:gnupg_module_name. There is an option to install gpg2 as gpg but for the other tools you would need to tell configure the full file name of the tools (e.g. --with-agent-pgm=/usr/local/bin/gpg2.1-gpg-agent) which is not that nice. You may want to file a bug so that we do not forget about this missing feature. > Out of curiosity (as I haven't had time to look deeply enough into the > source code yet), how does dirmngr handle SNI in the case of the hkps > pool being resolved to multiple client? Does it still present itself > as SNI=hkps.pool.sks-keyservers.net when contacting individual We uses the name of the actual server. Basically we do this: if (!getaddrinfo (name, NULL, &hints, &aibuf)) for (ai = aibuf; ai; ai = ai->ai_next) getnameinfo (ai, tmphost, sizeof tmphost) and then use TMPHOST to connect the host TMPHOST is the also given as SNI. If the server can't be resolved this is likely a problem because the code will use the IP address as server name. The HTTP code does not know about the pools, it takes an URL and applies proxy settings and resolves SRV records. Shalom-Salam, Werner From wk at gnupg.org Wed May 7 17:22:00 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 May 2014 17:22:00 +0200 Subject: [PATCH] Curve25519 for ECDH In-Reply-To: <87oazss0f7.fsf@vigenere.g10code.de> (Werner Koch's message of "Wed, 23 Apr 2014 14:19:40 +0200") References: <1398249926.2587.1.camel@cfw2.gniibe.org> <87oazss0f7.fsf@vigenere.g10code.de> Message-ID: <8738gl62cn.fsf@vigenere.g10code.de> On Wed, 23 Apr 2014 14:19, wk at gnupg.org said: > the name most people know about. With the addition of ECDH we will use > the appropriate appropriate curve depending on the use (Ed25519 for a > signing key and Curve25519 for an encryption key) Meanwhile I implemented full support for EdDSA and for that I changed ask_curve to #if GPG_USE_EDDSA { "Curve25519", 0, 0, 1, "Curve 25519" }, #endif [...] /* If the user selected a signing algorithm and Curve25519 we need to update the algo and and the curve name. */ if ((*algo == PUBKEY_ALGO_ECDSA || *algo == PUBKEY_ALGO_EDDSA) && curves[idx].fix_curve) { *algo = PUBKEY_ALGO_EDDSA; result = xstrdup ("Ed25519"); } else result = xstrdup (curves[idx].name); break; This seems to be the easiest way to support it. As soon as Curve25519+ECDH works the selection code should be able to create an Ed25519 primary key and a Curve25519 encryption subkey. As of now selecting "(9) ECC" does not work; you will get an "Unknown elliptic curve" error during the generation. Use "(10) ECC (sign only)" to test Ed25519. My change also changes the ECC import protocol between gpg and gpg-agent. gpg does not any longer passes the curve parameters but merely the name of the curve. That makes the code much easier to understand. Maybe you want to adjust and commit your Curve25519/ECDH patch from 2014-04-23. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Wed May 7 17:28:17 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 May 2014 17:28:17 +0200 Subject: SSH-agent / OpenPGP auth subkey issues In-Reply-To: <1399467970.6312.0.camel@latx1.gniibe.org> (NIIBE Yutaka's message of "Wed, 07 May 2014 22:06:10 +0900") References: <536A09CF.9050004@sumptuouscapital.com> <1399467970.6312.0.camel@latx1.gniibe.org> Message-ID: <87vbth4nhq.fsf@vigenere.g10code.de> On Wed, 7 May 2014 15:06, gniibe at fsij.org said: > Here is a possible fix. Sorry, I don't test it (my auth > keys are in my tokens). Looks correct. Please commit. It was my fault during re-factoring of the code. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kristian.fiskerstrand at sumptuouscapital.com Wed May 7 18:17:27 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 07 May 2014 18:17:27 +0200 Subject: Dirmngr now supports hkps In-Reply-To: <87bnv96358.fsf@vigenere.g10code.de> References: <5368A688.60005@sumptuouscapital.com> <878uqf7zab.fsf@vigenere.g10code.de> <53691FCA.4070207@sumptuouscapital.com> <87bnv96358.fsf@vigenere.g10code.de> Message-ID: <536A5C97.5060802@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/07/2014 05:04 PM, Werner Koch wrote: > On Tue, 6 May 2014 19:45, > kristian.fiskerstrand at sumptuouscapital.com said: > >> 8412a5825c225c8ff14de3ffaad2e55e040b2eca `make -j4` fails on my >> computer with ERROR described below. As of > > Fixed. > >> Also, if using --program-prefix='gpg2.1-' gpg fails to locate >> the dirmngr, > > Better use --prefix or --exec-prefix to put that version into a > different directory. To allow for an arbitrary prefix we need to > tell this common/homedir.c:gnupg_module_name. There is an option > to install gpg2 as gpg but for the other tools you would need to > tell configure the full file name of the tools Thanks for the pointer > (e.g. --with-agent-pgm=/usr/local/bin/gpg2.1-gpg-agent) which is > not that nice. You may want to file a bug so that we do not forget > about this missing feature. I'll play around with my live ebuild a bit and see if I get around to filing a bug once I get more familiar with the aforementioned options. > >> Out of curiosity (as I haven't had time to look deeply enough >> into the source code yet), how does dirmngr handle SNI in the >> case of the hkps pool being resolved to multiple client? Does it >> still present itself as SNI=hkps.pool.sks-keyservers.net when >> contacting individual > > We uses the name of the actual server. Basically we do this: > > if (!getaddrinfo (name, NULL, &hints, &aibuf)) for (ai = aibuf; ai; > ai = ai->ai_next) getnameinfo (ai, tmphost, sizeof tmphost) > > and then use TMPHOST to connect the host TMPHOST is the also given > as SNI. If the server can't be resolved this is likely a problem > because the code will use the IP address as server name. The HTTP > code does not know about the pools, it takes an URL and applies > proxy settings and resolves SRV records. Ok, this seems to be a problem, I'll try to explain why I think so. Certificates issued by the pool have (i) a CN with the server name, which corresponds to the hostname provided in the server's sksconf or similar and presented using /pks/lookup?op=stats and (ii) a subjectAltName of the pool addresses including hkps. Only IP addresses are provided for DNS request to the pools, as SRV records are currently disabled due to existing bugs 1446[0] and 1447[1]. Based on your description of the current dirmngr behaviour I foresee (at least) a few problems. (i) as tmphost is derived from getnameinfo, the PTR record will be used. A concrete example would be sks.karotte.org that resolve to 176.9.51.79 which has a PTR of alita.karotte.org. However no keyserver is configured on [2] as the expected host is [3]. So trying to grab a key will fail. (ii) iff we require the PTR to match the hostname of the keyservers in order to try to allow this behavior (keeping in mind that will limit some server administrator's possibility to participate in the pool as they might not be in control of the PTR records, or the sks service is on a similar IP with other services that are prioritized), we'd still have an issue in the situation where using the CN directly the server might be presenting a self-signed / corporate signed certificate for SNI == CN. In this case we will have a server authentication error (iii) If the server upon SNI == CN || is presenting a certificate signed by the CA Roots, we might nor might not get a valid authentication of the server, depending on whether the global root CA store on a calling client is consulted. I strongly suggest using the original hostname provided as SNI when performing keyserver lookups, this is also consistent with current behavior (some of these points are also valid for any virtual-hosting setup for the reverse proxy servers. It will most likely be more of an issue on the port 80 subpool than the main pool as we strongly encourage administrators to allow all traffic on 11371 through to the keyserver). References: [0] http://bugs.g10code.com/gnupg/issue1446 [1] http://bugs.g10code.com/gnupg/issue1447 [2] https://alita.karotte.org/pks/lookup?op=stats [3] https://sks.karotte.org/pks/lookup?op=stats - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Corruptissima re publica plurim? leges The greater the degeneration of the republic, the more of its laws -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTalyUAAoJEPw7F94F4TagJYcP/3KHZb4ybmOM4DDWus6y8qtZ 380SXFeiAyx6IkVecRggpU7kNwToV9ctzV1XaOlwR5aSlxjiVtRPa1wwYIuYGjm4 drqmMyGui6PPaI/bFXqqINfxQF9QQdAIEIqHb7f2Dey1I7z0KgepR5cfdcWQNMJF xMg7nOvr4xReFsqMnv9ta6hguS+MsJwWFcbWT5sSEGyRVv1wHCcOfkX4puOMSiM2 nmebD4CQG2wH/1i7dnb3govhHHZ1ViptZIYgHObBZgYRYWsvbTz8LNP2oEq1UOW9 VrO9BAiz8nfkjFDIHwpvviDpmSJflfKoAYVxi2Eixjl/lsc6Lo1niJKdERcOJa+c mejGGPq0p8mb3MNwejtOiGRMfRXs0XDbIjQsamB3ixkinS8+XZWpeqI8G9s3PR2V BoW58bymIeCC/tgx3LSVBuvUuLn73+BXQjCTGCpV1H/Xlwa/95L87H39SzAwDLur 3Dhv2MFi0hh1J44O9PWjfuFs8KLBPA6gNrejskRI9X6AKS2XTPTSmdPRP64T/W+s S/9TcV1mU7tHGpAGqngEIlsApIfmQMjeRO176EDcTKSUTWUWB3blE643pszuDPOa KaBJKmL3vLIltT6qg2YetmMoWhqgYyXl1R7t2S01OtPhO0a0Ho5n5N2hTZZe+KTJ UlIm7Ac/g9x89BCB67ZW =ox3V -----END PGP SIGNATURE----- From wk at gnupg.org Wed May 7 20:51:07 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 07 May 2014 20:51:07 +0200 Subject: Dirmngr now supports hkps In-Reply-To: <536A5C97.5060802@sumptuouscapital.com> (Kristian Fiskerstrand's message of "Wed, 07 May 2014 18:17:27 +0200") References: <5368A688.60005@sumptuouscapital.com> <878uqf7zab.fsf@vigenere.g10code.de> <53691FCA.4070207@sumptuouscapital.com> <87bnv96358.fsf@vigenere.g10code.de> <536A5C97.5060802@sumptuouscapital.com> Message-ID: <8761lh4e3o.fsf@vigenere.g10code.de> On Wed, 7 May 2014 18:17, kristian.fiskerstrand at sumptuouscapital.com said: > (i) as tmphost is derived from getnameinfo, the PTR record will be > used. A concrete example would be sks.karotte.org that resolve to > 176.9.51.79 which has a PTR of alita.karotte.org. However no keyserver > is configured on [2] as the expected host is [3]. So trying to grab a > key will fail. I considered that but first wanted to implement what I think is the Right Thing; i.e. I assumed properly configured servers and admins with full access to the DNS zones. > have an issue in the situation where using the CN directly the server > might be presenting a self-signed / corporate signed certificate for > SNI == CN. In this case we will have a server authentication error Hmmm. > I strongly suggest using the original hostname provided as SNI when > performing keyserver lookups, this is also consistent with current Okay. What about a dirmngr options to enable or disable the use of the pool name? Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kristian.fiskerstrand at sumptuouscapital.com Wed May 7 22:19:33 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Wed, 07 May 2014 22:19:33 +0200 Subject: Dirmngr now supports hkps In-Reply-To: <8761lh4e3o.fsf@vigenere.g10code.de> References: <5368A688.60005@sumptuouscapital.com> <878uqf7zab.fsf@vigenere.g10code.de> <53691FCA.4070207@sumptuouscapital.com> <87bnv96358.fsf@vigenere.g10code.de> <536A5C97.5060802@sumptuouscapital.com> <8761lh4e3o.fsf@vigenere.g10code.de> Message-ID: <536A9555.2080903@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/07/2014 08:51 PM, Werner Koch wrote: > On Wed, 7 May 2014 18:17, > kristian.fiskerstrand at sumptuouscapital.com said: > > >> I strongly suggest using the original hostname provided as SNI >> when performing keyserver lookups, this is also consistent with >> current > > Okay. What about a dirmngr options to enable or disable the use of > the pool name? As long as the hostname provided by the client is used by default for (i) HTTP Host: and; (ii) in the context of TLS for SNI (c.f. arguments similar to those presented in issue1447[0]) I don't have any arguments against a tunable option to change the behavior. References: [0] http://bugs.g10code.com/gnupg/issue1447 - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- Pr?venire melius est quam pr?veniri It is better to precede than to be preceded -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTapVVAAoJEPw7F94F4Tagkq4P/RdB/WuL8ZmH88fBzlHuFH5w T+7VDW507u2j16zDaY9gpQjkl+05HxFLvIw83QXdISqkGvyKp/PlBZdd4lDZtFja IxgoM9CHH8DhemUi3ws4KhYlMq8gnCOGCVAP13VzmOEZOq6mcb7KU6Meg7I2rBHk GzHmdw/tZzvdPOiUFrQ77wuDNJrx2rjVkdR96RZNgGQvHyPm/ldvGnsfz3xsmJYK YU1oa+6YL6rIfnDFGAwsOmdKLR0bszXVrT/LtuZfj3apjKNkYpecmI02avic2uq6 JJ8nOLRHFQp+m76+0ITuoI7oW62VXhuLrvL2D1/Eg8zXK40k0Xss63XhyQeKOVRX jaMwEt75bJ4zNBpD1cpsrh4gN9bgAFwoAxgcrYDcj4wfMzUytgNmvnSqEdr4eaSS +++ruyPZGHH+utFZvzLgulwdYoisJ+SAryd2Yf7BiwVfWumGxjEBycka0nxwXa2n Bc2X37ugzcJvF/mt9xgFT6ce6dKdq4F5HR85xfOZMaO51Rg0e/aDWNspdOkY/3zE 0uhhPpn7mU2tSLVLsQ3M8qAOs3ffVgZug3LCtY59caspYOX8jKjeqCwFEsLIXynl w6Yf0hugY8xvII2QUBVn2+ePB80+0w2eyyyTpHATAOi9QcC+wjsoEd8zLdXNt1U9 IvI0LwkK1p/9KO34wFXP =VYYE -----END PGP SIGNATURE----- From dkg at fifthhorseman.net Thu May 8 04:08:07 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 07 May 2014 23:08:07 -0300 Subject: forcing "--compress-algo Uncompressed" in gpgme In-Reply-To: <87k39x6743.fsf@vigenere.g10code.de> References: <87d2frwa4e.fsf@alice.fifthhorseman.net> <87k39x6743.fsf@vigenere.g10code.de> Message-ID: <536AE707.7090104@fifthhorseman.net> On 05/07/2014 10:39 AM, Werner Koch wrote: > On Tue, 6 May 2014 11:05, dkg at fifthhorseman.net said: >> Is there a way to do this that i'm missing? or does gpgme need to be >> extended to make this work? > > For encrypt and encrypt_sign it will be easy to add a flag > > GPGME_ENCRYPT_NO_COMPRESS = 16 This sounds reasonable, thanks. > But for a plain sign operation I see no easy way to convey such a flag. > OTOH, such a flag is does not see every useful in that case. yeah, i don't see as much of a concern about the compression on signed messages -- there's no need to guess at the content of the message based on the compressed size if the content is cleartext anyway. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From gniibe at fsij.org Thu May 8 04:49:27 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Thu, 08 May 2014 11:49:27 +0900 Subject: SSH-agent / OpenPGP auth subkey issues In-Reply-To: <87vbth4nhq.fsf@vigenere.g10code.de> References: <536A09CF.9050004@sumptuouscapital.com> <1399467970.6312.0.camel@latx1.gniibe.org> <87vbth4nhq.fsf@vigenere.g10code.de> Message-ID: <1399517367.7410.0.camel@cfw2.gniibe.org> On 2014-05-07 at 17:28 +0200, Werner Koch wrote: > Looks correct. Please commit. It was my fault during re-factoring of > the code. Committed and pushed. -- From wk at gnupg.org Thu May 8 11:33:45 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 08 May 2014 11:33:45 +0200 Subject: forcing "--compress-algo Uncompressed" in gpgme In-Reply-To: <536AE707.7090104@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Wed, 07 May 2014 23:08:07 -0300") References: <87d2frwa4e.fsf@alice.fifthhorseman.net> <87k39x6743.fsf@vigenere.g10code.de> <536AE707.7090104@fifthhorseman.net> Message-ID: <87ha50398m.fsf@vigenere.g10code.de> On Thu, 8 May 2014 04:08, dkg at fifthhorseman.net said: >> GPGME_ENCRYPT_NO_COMPRESS = 16 > > This sounds reasonable, thanks. Committed and pushed to gpgme master. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dshaw at jabberwocky.com Thu May 8 17:10:45 2014 From: dshaw at jabberwocky.com (David Shaw) Date: Thu, 8 May 2014 11:10:45 -0400 Subject: [PATCH] 1.4.x: Fix PC/SC In-Reply-To: <1398913769.3081.7.camel@cfw2.gniibe.org> References: <1398913769.3081.7.camel@cfw2.gniibe.org> Message-ID: <7A32A47D-E443-4891-BB86-D25503ED79F7@jabberwocky.com> On Apr 30, 2014, at 11:09 PM, NIIBE Yutaka wrote: > Hello, > > For the issue 1358, I fixed 2.0 (and master branch) but not 1.4. > https://bugs.g10code.com/gnupg/issue1358 > > I thought MacOS X user used 2.0 or internal driver, but it seems > wrong. > > Here is a patch to 1.4, backported. Building on x86 has no problem. The patch works very well for me on OSX 10.9.2 ("Mavericks"). David From gnupg-devel at spodhuis.org Thu May 8 20:28:00 2014 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Thu, 8 May 2014 14:28:00 -0400 Subject: Dirmngr now supports hkps In-Reply-To: <536A9555.2080903@sumptuouscapital.com> References: <5368A688.60005@sumptuouscapital.com> <878uqf7zab.fsf@vigenere.g10code.de> <53691FCA.4070207@sumptuouscapital.com> <87bnv96358.fsf@vigenere.g10code.de> <536A5C97.5060802@sumptuouscapital.com> <8761lh4e3o.fsf@vigenere.g10code.de> <536A9555.2080903@sumptuouscapital.com> Message-ID: <20140508182800.GA31682@redoubt.spodhuis.org> On 2014-05-07 at 22:19 +0200, Kristian Fiskerstrand wrote: > On 05/07/2014 08:51 PM, Werner Koch wrote: > > On Wed, 7 May 2014 18:17, > > kristian.fiskerstrand at sumptuouscapital.com said: > >> I strongly suggest using the original hostname provided as SNI > >> when performing keyserver lookups, this is also consistent with > >> current > > > > Okay. What about a dirmngr options to enable or disable the use of > > the pool name? > > As long as the hostname provided by the client is used by default for > (i) HTTP Host: and; (ii) in the context of TLS for SNI (c.f. arguments > similar to those presented in issue1447[0]) I don't have any arguments > against a tunable option to change the behavior. Likewise, but I'll emphasize that the default needs to be to use the original supplied hostname (ie, poolname) instead of the resolved server name. Remember that each keyserver is independently run. It's fairly rare for one organisation to run more than one keyserver in the public pools (except behind loadbalancers, to present as one). The pool names are a layer above that and are not privileged. Anyone can run a pool. This egalitarianism is deliberate, and avoids a few issues: we have two sets of open source software for spidering the keyservers and maintaining public pools, so anyone who disagrees with a decision by Kristian can quite legitimately be told to run their own pool definition and pointed at resources to help them do so. The only complexity is when adding hostname verification to the mix; up until that point, any keyserver which is a candidate for inclusion in pools using Kristian's software has been verified to handle unknown Host: headers and still work, so that aliases such as "keys.gnupg.net" will work. So my keyserver, which presents to end-users as "sks.spodhuis.org", has a cert from my own CA for that vhost and dispatches on SNI to select it. For the hostname hkps.pool.sks-keyservers.net, I have a separate key/cert pair and the cert is signed by Kristian's CA. I am willing to work with others, if I recognise them and don't have particular reason to object, to add more keys/certs for other hostnames representing pools. Each keyserver _is_ in N1 pools. It can be in N2 HKPS pools. It happens that at present there's only one HKPS pool, but given some of the demands being made on the sks mailing-list now, on CA practices for the demo HKPS pool run by Kristian, I think and _hope_ that we'll soon see some more. Each pool necessarily uses its own CA. No one CA can be enforced or reasonably required as being used for hostnames other than the pool name. Thus HKPS clients should default to preserving the original hostname if they want to be able to select a CA based on the pool. The current design of CA management/selection for keyservers in GnuPG, including the new dirmngr support, has to use the pool name in TLS SNI and Host: to work. If someone wants to design another validation mechanism for TLS public keys when used for HKPS, perhaps based around OpenPGP (Monkeysphere?) then that might be worthwhile to pursue. From cloos at jhcloos.com Fri May 9 02:14:56 2014 From: cloos at jhcloos.com (James Cloos) Date: Thu, 08 May 2014 20:14:56 -0400 Subject: [Sks-devel] Dirmngr now supports hkps In-Reply-To: <20140508182800.GA31682@redoubt.spodhuis.org> (Phil Pennock's message of "Thu, 8 May 2014 14:28:00 -0400") References: <5368A688.60005@sumptuouscapital.com> <878uqf7zab.fsf@vigenere.g10code.de> <53691FCA.4070207@sumptuouscapital.com> <87bnv96358.fsf@vigenere.g10code.de> <536A5C97.5060802@sumptuouscapital.com> <8761lh4e3o.fsf@vigenere.g10code.de> <536A9555.2080903@sumptuouscapital.com> <20140508182800.GA31682@redoubt.spodhuis.org> Message-ID: >>>>> "PP" == Phil Pennock writes: PP> If someone wants to design another validation mechanism for TLS PP> public keys when used for HKPS, perhaps based around OpenPGP PP> (Monkeysphere?) then that might be worthwhile to pursue. Now that sks-keyservers.net6. is signed, it would be useful to add TLSA RRs at: _443._tcp.hkps.pool.sks-keyservers.net. _11372._tcp.hkps.pool.sks-keyservers.net. referencing the sks-keyservers' CA. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From dkg at fifthhorseman.net Fri May 9 22:59:40 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 09 May 2014 17:59:40 -0300 Subject: Dirmngr now supports hkps In-Reply-To: <8761lh4e3o.fsf@vigenere.g10code.de> References: <5368A688.60005@sumptuouscapital.com> <878uqf7zab.fsf@vigenere.g10code.de> <53691FCA.4070207@sumptuouscapital.com> <87bnv96358.fsf@vigenere.g10code.de> <536A5C97.5060802@sumptuouscapital.com> <8761lh4e3o.fsf@vigenere.g10code.de> Message-ID: <536D41BC.3050208@fifthhorseman.net> On 05/07/2014 03:51 PM, Werner Koch wrote: > On Wed, 7 May 2014 18:17, kristian.fiskerstrand at sumptuouscapital.com said: >> I strongly suggest using the original hostname provided as SNI when >> performing keyserver lookups, this is also consistent with current > > Okay. What about a dirmngr options to enable or disable the use of the > pool name? I agree with Kristian that the name given by the user should be the name sent to the remote server, and should also be the name checked against the certificate. Using a DNS reverse lookup to modify the name supplied to the remote host is a violation of the security assumptions that underpin the goal of using TLS in this case. If i understand the reverse DNS lookup Werner is describing correctly, an attacker capable of spoofing the DNS should be able to modify the name that the client expects. C: Client D: DNS resolver (could be compromised) S: server C?D: give me the address for keys.example.org D?C: keys.example.org is at 192.0.2.3 C?D: what is the name for 192.0.2.3? D?C: the name for 192.0.2.3 is evilsite.example C?S: hi, i would like evilsite.example S?C: sure, here is my certificate for evilsite.example So any S just needs a certificate for *any* domain from a trusted X.509 root authority, if the attacker able to take over or poison D. Kerberos used to do a similar DNS reverse lookup, and they no longer recommend doing it because of the same security concerns. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From nicholas.cole at gmail.com Sun May 11 11:01:15 2014 From: nicholas.cole at gmail.com (Nicholas Cole) Date: Sun, 11 May 2014 10:01:15 +0100 Subject: Agent socket security Message-ID: Dear list, This is a question that comes out of my own ignorance, but what stops one user on a system maliciously connecting to another user's gpg-agent, and is this mechanism secure on all platforms? After all, isn't gpg-agent listening on a socket for commands? Presumably it is hard to authenticate whether the source of those commands is legitimate. Is this the mechanism being relied on? http://unix.stackexchange.com/questions/83032/which-systems-do-not-honor-socket-read-write-permissions I presume listening on a network socket would simply be impossible to trust (without some separate username/password). I'm sure I must be missing something, so forgive the naive question! N -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Sun May 11 15:58:50 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 11 May 2014 10:58:50 -0300 Subject: Agent socket security In-Reply-To: References: Message-ID: <536F821A.4070006@fifthhorseman.net> On 05/11/2014 06:01 AM, Nicholas Cole wrote: > This is a question that comes out of my own ignorance, but what stops one > user on a system maliciously connecting to another user's gpg-agent, and is > this mechanism secure on all platforms? there are at least two mechanisms that can be used: filesystem permissions, and socket peer credentials (e.g.SO_PEERCRED). All unix-style systems will support filesystem permissions. Not all unix systems support socket peer credentials. here's how filesystem permissions work: the directory that the socket lives in is unreadable and unwritable and untraversable by anyone but the owner. this protects access to the socket. for example: 0 dkg at alice:~$ cat .gnupg/gpg-agent-info GPG_AGENT_INFO=/tmp/gpg-gXXXXX/S.gpg-agent:6869:1; export GPG_AGENT_INFO; 0 dkg at alice:~$ ls -la /tmp/gpg-XXXXX/ total 0 drwx------ 2 dkg dkg 60 May 10 13:19 . drwxrwxrwt 9 root root 260 May 11 10:45 .. srwxr-xr-x 1 dkg dkg 0 May 10 13:19 S.gpg-agent 0 dkg at alice:~$ socket peer credentials are derived from the socket by libassuan, which abstracts away the several different forms of socket peer credentials that different OSes use (see src/assuan-socket-server.c from git://git.gnupg.org/libassuan.git). In the master branch, dirmngr appears to use assuan's report of the socket's peer credentials. From a quick scan of the source, I don't think it is used in gnupg 2.0 or 1.4. (that is, i think they rely strictly on the filesystem permissions; hopefully someone more knowledgeable will correct me if i've got this wrong). hth, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon May 12 12:25:38 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 May 2014 12:25:38 +0200 Subject: Agent socket security In-Reply-To: <536F821A.4070006@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Sun, 11 May 2014 10:58:50 -0300") References: <536F821A.4070006@fifthhorseman.net> Message-ID: <87siofxpi5.fsf@vigenere.g10code.de> On Sun, 11 May 2014 15:58, dkg at fifthhorseman.net said: > think it is used in gnupg 2.0 or 1.4. (that is, i think they rely > strictly on the filesystem permissions; hopefully someone more > knowledgeable will correct me if i've got this wrong). That is correct. The sockets are created in the ~/.gnupg directly which should have appropriate permissions anyway (gpg shows a warning if not) or in a temporary directly created for the user. Obviously the umask should now allow others to write to the socket. The dirmngr is either a system wide daemon and creates a socket below /var/run/gnupg or creates the socket below ~/.gnupg. Dirmngr is by design a system wide services but with 2.1 the default changes to be a per-user service. Under Windows file system permissions are used in a similar way. Actually a plain file is used which has a local TCP port number and a nonce to emulate Unix style sockets. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dkg at fifthhorseman.net Mon May 12 14:05:15 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 12 May 2014 08:05:15 -0400 Subject: Agent socket security In-Reply-To: <87siofxpi5.fsf@vigenere.g10code.de> References: <536F821A.4070006@fifthhorseman.net> <87siofxpi5.fsf@vigenere.g10code.de> Message-ID: <5370B8FB.8020203@fifthhorseman.net> Hi Werner-- Thanks for the confirmation. On 05/12/2014 06:25 AM, Werner Koch wrote: > That is correct. The sockets are created in the ~/.gnupg directly which > should have appropriate permissions anyway (gpg shows a warning if not) > or in a temporary directly created for the user. Obviously the umask > should now allow others to write to the socket. I think you mean "should not allow" above, right? Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1010 bytes Desc: OpenPGP digital signature URL: From wk at gnupg.org Mon May 12 15:04:04 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 12 May 2014 15:04:04 +0200 Subject: Agent socket security In-Reply-To: <5370B8FB.8020203@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Mon, 12 May 2014 08:05:15 -0400") References: <536F821A.4070006@fifthhorseman.net> <87siofxpi5.fsf@vigenere.g10code.de> <5370B8FB.8020203@fifthhorseman.net> Message-ID: <87ppjjw3ln.fsf@vigenere.g10code.de> On Mon, 12 May 2014 14:05, dkg at fifthhorseman.net said: >> or in a temporary directly created for the user. Obviously the umask >> should now allow others to write to the socket. > > I think you mean "should not allow" above, right? Yes. -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From richard.purdie at linuxfoundation.org Tue May 13 14:55:29 2014 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Tue, 13 May 2014 13:55:29 +0100 Subject: Use of pkg-config Message-ID: <1399985729.31891.165.camel@ted> I notice this has been mentioned back in 2012 but I'd like to ask again whether it would be possible to consider adding pkgconfig support to libgpg-error and friends? Why? pkgconfig is the more friendly way to cross compile things these days. It does the same thing as the -config scripts but does so in a standardised file format with standardised tooling to access them and standardised macros. Many projects have now switched over. One comment in the previous discussion was "Package using pkgconfig require a wrapper to fix the paths. Checkout the Gpg4win meta installer for details.". Whilst there were times in the past when you did need to fix some paths with pkgconfig, sysroot support was added to pkgconfig upstream some time ago and certainly the OpenEmbedded+Yocto projects have been using it for a long time without issue, certainly no need to fix paths. I would add that we do need to fix paths with the current raft of -config scripts out there however as these do not have the notion of a sysroot. Compare and contrast our config handler: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/binconfig.bbclass with the effectively empty file of pkgconfig: http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/pkgconfig.bbclass (git history will show this was not always the case but it is now). The big win is that you can configure a target system layout, yet still use the same files from "make install" on a build system as long as specify that the directory containing the target files is a sysroot. This is the same mechanism supported by all the major tooling including the toolchain. So if I were to propose some pkg-config patches, would there be any interest in them? Cheers, Richard From wk at gnupg.org Wed May 14 17:20:31 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 May 2014 17:20:31 +0200 Subject: Use of pkg-config In-Reply-To: <1399985729.31891.165.camel@ted> (Richard Purdie's message of "Tue, 13 May 2014 13:55:29 +0100") References: <1399985729.31891.165.camel@ted> Message-ID: <87y4y4s7y8.fsf@vigenere.g10code.de> On Tue, 13 May 2014 14:55, richard.purdie at linuxfoundation.org said: > I notice this has been mentioned back in 2012 but I'd like to ask again > whether it would be possible to consider adding pkgconfig support to > libgpg-error and friends? No. pkg-config is mess because it is not based on standard Unix tools but introduces extra dependencies. The idea behind ./configure is to be able to run the build process on an arbitrary Unix box without extra dependencies. pkg-config introduces such extra dependencies because of itself and - even worse - because it depends on glib. Yes, I am talking about generic Unix systems. There are still other systems in active use than Linux, Windows, and MacOS. Those systems don't come with pkg-config or glib installed as standard tools. They don't come with GNU make but with a standard make. This is why we need most of the configure stuff. pkg-config makes sense for projects like GNOME and KDE where it is part of their framework. > One comment in the previous discussion was "Package using pkgconfig > require a wrapper to fix the paths. Checkout the Gpg4win meta installer > for details.". Agreed, that is not a problem anymore. The new 2.1 Windows build code uses pkg-config without a wrapper for building GPA (GTK+ based GUI). Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From richard.purdie at linuxfoundation.org Wed May 14 17:59:33 2014 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Wed, 14 May 2014 16:59:33 +0100 Subject: Use of pkg-config In-Reply-To: <87y4y4s7y8.fsf@vigenere.g10code.de> References: <1399985729.31891.165.camel@ted> <87y4y4s7y8.fsf@vigenere.g10code.de> Message-ID: <1400083173.31891.246.camel@ted> On Wed, 2014-05-14 at 17:20 +0200, Werner Koch wrote: > On Tue, 13 May 2014 14:55, richard.purdie at linuxfoundation.org said: > > I notice this has been mentioned back in 2012 but I'd like to ask again > > whether it would be possible to consider adding pkgconfig support to > > libgpg-error and friends? > > No. > > pkg-config is mess because it is not based on standard Unix tools but > introduces extra dependencies. The idea behind ./configure is to be > able to run the build process on an arbitrary Unix box without extra > dependencies. pkg-config introduces such extra dependencies because of > itself and - even worse - because it depends on glib. > > Yes, I am talking about generic Unix systems. There are still other > systems in active use than Linux, Windows, and MacOS. Those systems > don't come with pkg-config or glib installed as standard tools. They > don't come with GNU make but with a standard make. This is why we need > most of the configure stuff. > > pkg-config makes sense for projects like GNOME and KDE where it is part > of their framework. Its worth highlighting that pkg-config has now standardised on using its own internal glib code so it no longer has that dependency, its handled internally. It only ever needed a tiny part of glib so this makes a lot of sense. Since that is now addressed does that help improve the situation to a point its use could be reconsidered? I appreciate the idea configure is standalone however it is now a single dependency which is widely available and widely used in many other pieces of software. Alternatively, could pkg-config be added as an option? It could be used by default and things could then fall back to the -config scripts? Cheers, Richard From wk at gnupg.org Wed May 14 19:33:18 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 14 May 2014 19:33:18 +0200 Subject: Use of pkg-config In-Reply-To: <1400083173.31891.246.camel@ted> (Richard Purdie's message of "Wed, 14 May 2014 16:59:33 +0100") References: <1399985729.31891.165.camel@ted> <87y4y4s7y8.fsf@vigenere.g10code.de> <1400083173.31891.246.camel@ted> Message-ID: <87bnv0s1sx.fsf@vigenere.g10code.de> On Wed, 14 May 2014 17:59, richard.purdie at linuxfoundation.org said: > Its worth highlighting that pkg-config has now standardised on using its > own internal glib code so it no longer has that dependency, its handled Okay. > of sense. Since that is now addressed does that help improve the > situation to a point its use could be reconsidered? Request an addition to POSIX and I will reconsider it. > Alternatively, could pkg-config be added as an option? It could be used > by default and things could then fall back to the -config scripts? No. The configure script along with the autoconf macros is how the gnupg related stuff is to be build. If there is a problem, please file a bug. Frankly, I don't see the reason for the request to use pkg-config. The *-config script approach is much more flexible and easier to maintain. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gnupg-devel at spodhuis.org Wed May 14 20:42:59 2014 From: gnupg-devel at spodhuis.org (Phil Pennock) Date: Wed, 14 May 2014 14:42:59 -0400 Subject: Use of pkg-config In-Reply-To: <87y4y4s7y8.fsf@vigenere.g10code.de> References: <1399985729.31891.165.camel@ted> <87y4y4s7y8.fsf@vigenere.g10code.de> Message-ID: <20140514184259.GA26340@redoubt.spodhuis.org> On 2014-05-14 at 17:20 +0200, Werner Koch wrote: > pkg-config is mess because it is not based on standard Unix tools but > introduces extra dependencies. The idea behind ./configure is to be > able to run the build process on an arbitrary Unix box without extra > dependencies. pkg-config introduces such extra dependencies because of > itself and - even worse - because it depends on glib. > > Yes, I am talking about generic Unix systems. There are still other > systems in active use than Linux, Windows, and MacOS. Those systems > don't come with pkg-config or glib installed as standard tools. They > don't come with GNU make but with a standard make. This is why we need > most of the configure stuff. > > pkg-config makes sense for projects like GNOME and KDE where it is part > of their framework. FreeBSD Ports includes "pkgconf", written from scratch to have few dependencies, after pkg-config switched to requiring pkg-config to build pkg-config. FWIW, the idea of template files is sane, and so is making life easier where the tools are available to do so. Thus I switched the Exim build system so that while you _can_ still modify the includes and library paths to explicitly link various libraries, you can also just say "AUTH_GSASL_PC=libgsasl" and the build framework will use `pkg-config --cflags libgsasl` for finding these arguments automatically. The results still go into the same place. It just makes it easier to adapt for various platforms. By providing commented-out examples for each module, we make life easier for the porters/packagers who have pkg-config or are willing to depend upon it, while still letting anyone and everyone do things the long way around. The results plumb into the same configuration variables which would be set by doing things the long way, so if we break the long way around, we also break pkg-config -- we don't risk rot. I think _requiring_ pkg-config is a mistake, you're completely right. Being able to _optionally_ use pkg-config, if it's available, to make life easier, is worth considering. -- My employer, Apcera Inc, is hiring sysadmin; primarily San Francisco: http://www.apcera.com/jobs/#operations-engineer (but all the mistakes in this email are made in my personal capacity) From wk at gnupg.org Thu May 15 11:53:01 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 15 May 2014 11:53:01 +0200 Subject: [Sks-devel] Dirmngr now supports hkps In-Reply-To: (James Cloos's message of "Thu, 08 May 2014 20:14:56 -0400") References: <5368A688.60005@sumptuouscapital.com> <878uqf7zab.fsf@vigenere.g10code.de> <53691FCA.4070207@sumptuouscapital.com> <87bnv96358.fsf@vigenere.g10code.de> <536A5C97.5060802@sumptuouscapital.com> <8761lh4e3o.fsf@vigenere.g10code.de> <536A9555.2080903@sumptuouscapital.com> <20140508182800.GA31682@redoubt.spodhuis.org> Message-ID: <874n0rqsg2.fsf@vigenere.g10code.de> On Fri, 9 May 2014 02:14, cloos at jhcloos.com said: > Now that sks-keyservers.net6. is signed, it would be useful to add > TLSA RRs at: Sure. However, I would really like to get a new beta out and not keep on adding useful features without having a a working and beta released code base. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From wk at gnupg.org Thu May 15 12:07:37 2014 From: wk at gnupg.org (Werner Koch) Date: Thu, 15 May 2014 12:07:37 +0200 Subject: Dirmngr now supports hkps In-Reply-To: <536D41BC.3050208@fifthhorseman.net> (Daniel Kahn Gillmor's message of "Fri, 09 May 2014 17:59:40 -0300") References: <5368A688.60005@sumptuouscapital.com> <878uqf7zab.fsf@vigenere.g10code.de> <53691FCA.4070207@sumptuouscapital.com> <87bnv96358.fsf@vigenere.g10code.de> <536A5C97.5060802@sumptuouscapital.com> <8761lh4e3o.fsf@vigenere.g10code.de> <536D41BC.3050208@fifthhorseman.net> Message-ID: <87zjijpd7a.fsf@vigenere.g10code.de> Hi, thanks for the comments. To get things straight, let me summarize my understanding: For plain HTTP: - No change to the current code or - Resolve the name while following CNAME records to get a list of IP addresses. Then connect any server at its IP address but use the canonical name of the pool (the one which yields the AAAA records) for the Host: header. For HTTPS: - Resolve the name while following CNAME records to get a list of IP addresses. Then connect any server at its IP address but use the canonical name of the pool (the one which yields the AAAA records) for the Host: header. Use that host: Header name also for SNI. In all cases make this the default behaviour if the hkp or the hkps is used for the keyserver URL. If http or https is used, do the same or use a different approach (e.g. let the DNS resolver decide)? Use of SRV records is subject to bug 1447 and will be fixed in a second step? Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From kristian.fiskerstrand at sumptuouscapital.com Thu May 15 17:50:17 2014 From: kristian.fiskerstrand at sumptuouscapital.com (Kristian Fiskerstrand) Date: Thu, 15 May 2014 17:50:17 +0200 Subject: Dirmngr now supports hkps In-Reply-To: <87zjijpd7a.fsf@vigenere.g10code.de> References: <5368A688.60005@sumptuouscapital.com> <878uqf7zab.fsf@vigenere.g10code.de> <53691FCA.4070207@sumptuouscapital.com> <87bnv96358.fsf@vigenere.g10code.de> <536A5C97.5060802@sumptuouscapital.com> <8761lh4e3o.fsf@vigenere.g10code.de> <536D41BC.3050208@fifthhorseman.net> <87zjijpd7a.fsf@vigenere.g10code.de> Message-ID: <5374E239.4050406@sumptuouscapital.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/15/2014 12:07 PM, Werner Koch wrote: > Hi, > > thanks for the comments. To get things straight, let me summarize > my understanding: > > For plain HTTP: > > - No change to the current code > > or > > - Resolve the name while following CNAME records to get a list of > IP addresses. Then connect any server at its IP address but use > the canonical name of the pool (the one which yields the AAAA > records) for the Host: header. > > > For HTTPS: > > - Resolve the name while following CNAME records to get a list of > IP addresses. Then connect any server at its IP address but use > the canonical name of the pool (the one which yields the AAAA > records) for the Host: header. Use that host: Header name also for > SNI. > > > In all cases make this the default behaviour if the hkp or the hkps > is used for the keyserver URL. If http or https is used, do the > same or use a different approach (e.g. let the DNS resolver > decide)? I'd expect the same issues wrt Host: (for virtual hosting sites) for http and https, as well as SNI for the latter for these protocols as for hkp(s). The rest sounds good to me. > > Use of SRV records is subject to bug 1447 and will be fixed in a > second step? This is indeed currently disabled in the pool so it won't create an issue in the short term and can be postponed to get a working beta out from my point of view. - -- - ---------------------------- Kristian Fiskerstrand Blog: http://blog.sumptuouscapital.com Twitter: @krifisk - ---------------------------- Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 - ---------------------------- "We can only see a short distance ahead, but we can see plenty there that needs to be done." (Alan Turing) -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTdOI1AAoJEPw7F94F4Tag0QEQAIwVRNXzYzEwR54Ca1rzaEQA WsmiMuavhUftBo0af5KxsBizbE2fUbl6atUTOUUJVA5ySIPi9qNrGHPgxu2Ut8V3 Z9m8YJSIGKwc1R2eK3ix0W5UF1bD1pEd8TgAkX79LzqgCGFwuqFBoLBU+iEFD4Vb puUAdik9UwhkECESW91L6B751v4sUNJulaQGQGmI5FodOfHCow2LaT+rDJ7QhjJa oyG2cTblq+sy44Sk4/Bhq/2xiZVBXwhGLWl4Stx69LGi2g5qLT+G5loLGTTEqEcn BsR3uYACa6GKK+TvXJGifBLa9EkcmcfMdienQbfbWutbDuwosq3rY2YBTcPOa+Oc llqWzD5FNhaRdGojW3LMU4+l2WY3znQsv8jY0I88MDzEnU/prQzZ5s5PB5QS74oC NRh2GW4dw1DNqBt6/DFLJy7VlA7s9pLrXZbh8vY2iH2ySsMVuOhX9OYFcqljROmr zG2up5y+X9v5GNpIoejKLpdlVGDiA+3Y1n4OGPQ6whvI8ZvyEg4t+bhAzMxN3Zgh fLhm5BwmYTvQ45hO+OEjHKd3ugOrM8ZrYe1hQogsKg43Cyj7vRTeXCJRdeywyACS vKS3lZE/Wu6JhwPbCOz8yp49iIYyrrHK4sXoMZBOZZ9DIybvIX1/LpsEOpPOVpeg vjjDhvi+DxbOzU12/FZp =hzwA -----END PGP SIGNATURE----- From wk at gnupg.org Mon May 19 10:10:53 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 19 May 2014 10:10:53 +0200 Subject: Dirmngr now supports hkps In-Reply-To: <20140508182800.GA31682@redoubt.spodhuis.org> (Phil Pennock's message of "Thu, 8 May 2014 14:28:00 -0400") References: <5368A688.60005@sumptuouscapital.com> <878uqf7zab.fsf@vigenere.g10code.de> <53691FCA.4070207@sumptuouscapital.com> <87bnv96358.fsf@vigenere.g10code.de> <536A5C97.5060802@sumptuouscapital.com> <8761lh4e3o.fsf@vigenere.g10code.de> <536A9555.2080903@sumptuouscapital.com> <20140508182800.GA31682@redoubt.spodhuis.org> Message-ID: <87lhtynq7m.fsf@vigenere.g10code.de> On Thu, 8 May 2014 20:28, gnupg-devel at spodhuis.org said: > they want to be able to select a CA based on the pool. The current > design of CA management/selection for keyservers in GnuPG, including the > new dirmngr support, has to use the pool name in TLS SNI and Host: to I changed that. If Dirmngr figures that the given keyserver is a pool (more than one A or AAAA record), it used the canonical name of the pool for Host and SNI. If it it is not a pool the the name is passed verbatim to the http layer. I also added some debug code to print the server certificates on failed. DNS names are missing in the output but will be added soon. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From Vincent.Riera at imgtec.com Mon May 19 12:25:45 2014 From: Vincent.Riera at imgtec.com (Vicente Olivert Riera) Date: Mon, 19 May 2014 11:25:45 +0100 Subject: gnupg-1.4.* fails to compile with uClibc Message-ID: <5379DC29.1040403@imgtec.com> Hello, could any gnupg developer take a look to this bug report, please? https://bugs.g10code.com/gnupg/issue1642 Thanks. -- Vincent From wk at gnupg.org Wed May 21 09:57:28 2014 From: wk at gnupg.org (Werner Koch) Date: Wed, 21 May 2014 09:57:28 +0200 Subject: [Announce] GPGME 1.5.0 released Message-ID: <87d2f71s47.fsf@vigenere.g10code.de> Hello! I am pleased to announce version 1.5.0 of GPGME. GnuPG Made Easy (GPGME) is a C language library that allows to add support for cryptography to a program. It is designed to make access to public key crypto engines as included in GnuPG easier for applications. GPGME provides a high-level crypto API for encryption, decryption, signing, signature verification, and key management. * Noteworthy changes in version 1.5.0 (2014-05-21) - On Unices the engine file names are not not anymore hardwired but located via the envvar PATH. All options to set the name of the engines for the configure run are removed. - If GPGME finds the gpgconf binary it defaults to using gpg2 or whatever gpgconf tells as name for the OpenPGP engine. If gpgconf is not found, GPGME looks for an engine named "gpg". - New feature to use the gpgme I/O subsystem to run arbitrary commands. - New flag to use encryption without the default compression step. - New function to access "gpg-conf --list-dirs" - New configure option --enable-fixed-path for use by Android. - Support ECC algorithms. - Interface changes relative to the 1.4.3 release: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ gpgme_get_dirinfo NEW. gpgme_op_spawn_start NEW. gpgme_op_spawn NEW. GPGME_PROTOCOL_SPAWN NEW. GPGME_SPAWN_DETACHED NEW. GPGME_SPAWN_ALLOW_SET_FG NEW. GPGME_ENCRYPT_NO_COMPRESS NEW. GPGME_PK_ECC NEW. GPGME_MD_SHA224 NEW. gpgme_subkey_t EXTENDED: New field curve. GPGME_STATUS_PLAINTEXT_LENGTH NEW. GPGME_STATUS_MOUNTPOINT NEW. GPGME_STATUS_PINENTRY_LAUNCHED NEW. GPGME_STATUS_ATTRIBUTE NEW. GPGME_STATUS_BEGIN_SIGNING NEW. GPGME_STATUS_KEY_NOT_CREATED NEW. * Download You may download this library and its OpenPGP signature from: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.5.0.tar.bz2 (942k) ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.5.0.tar.bz2.sig GZIP compressed tarballs are also available: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.5.0.tar.gz (1214k) ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.5.0.tar.gz.sig As an alternative you may use a patch file to upgrade the previous version of the library: ftp://ftp.gnupg.org/gcrypt/gpgme/gpgme-1.4.3-1.5.0.diff.bz2 (51k) SHA-1 checksums are: 690df6d692be36923b9b28530afb2b4854f2435d gpgme-1.5.0.tar.bz2 3f6d34b4a9a2cce67891fef384f59a0d8ec7a2d5 gpgme-1.5.0.tar.gz 7138547fa8f0ba71810aee4a5a0d3e0612df8c2a gpgme-1.4.3-1.5.0.diff.bz2 * Support Please send questions regarding the use of GPGME to the gnupg-devel mailing list: http://lists.gnupg.org/mailman/listinfo/gnupg-devel/ If you need commercial support, you may want to consult this listing: http://www.gnupg.org/service.html The driving force behind the development of the GnuPG system is my company g10 Code. Maintenance and improvement of GnuPG and related software takes up most of our resources. To allow us to continue our work on free software, we ask to either purchase a support contract, engage us for custom enhancements, or to donate money: http://g10code.com/gnupg-donation.html Happy hacking, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 180 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 richard.purdie at linuxfoundation.org Thu May 22 11:10:04 2014 From: richard.purdie at linuxfoundation.org (Richard Purdie) Date: Thu, 22 May 2014 10:10:04 +0100 Subject: Use of pkg-config In-Reply-To: <87bnv0s1sx.fsf@vigenere.g10code.de> References: <1399985729.31891.165.camel@ted> <87y4y4s7y8.fsf@vigenere.g10code.de> <1400083173.31891.246.camel@ted> <87bnv0s1sx.fsf@vigenere.g10code.de> Message-ID: <1400749804.17834.55.camel@ted> On Wed, 2014-05-14 at 19:33 +0200, Werner Koch wrote: > On Wed, 14 May 2014 17:59, richard.purdie at linuxfoundation.org said: > > > Its worth highlighting that pkg-config has now standardised on using its > > own internal glib code so it no longer has that dependency, its handled > > Okay. > > > of sense. Since that is now addressed does that help improve the > > situation to a point its use could be reconsidered? > > Request an addition to POSIX and I will reconsider it. > > > Alternatively, could pkg-config be added as an option? It could be used > > by default and things could then fall back to the -config scripts? > > No. The configure script along with the autoconf macros is how the > gnupg related stuff is to be build. If there is a problem, please file > a bug. Frankly, I don't see the reason for the request to use > pkg-config. The *-config script approach is much more flexible and > easier to maintain. Let me explain the problem. I lead a cross compiling build project (OpenEmbedded/Yocto Project) so I have some experience at cross compiling. When we build libfoo with libdir=/usr/lib (since this is where the library will live on target), we install it into a DESTDIR so it ends up in DESTDIR/usr/lib/libfoo and DESDIR/usr/bin/foo-config. We want to do two things with these files, package them up and use them on target and also, install them into our sysroot that we're using for cross compiling. On target, if we run foo-config, it returns things like -L/usr/lib (as its a default search path it may well get suppressed but you get the idea). This is all well and good. The trouble is that within our cross envrionment where its within the sysroot, it will also return -L/usr/lib and this is the build system, not the target system and causes us all kinds of issues. We basically have two options: a) Build things twice, once with sysroot paths and once for the target. That is rather inefficient and isn't always successful either. b) Hack the -config scripts in one/both cases to ensure the right paths get added in. We do b). We get all kinds of problems as -config scripts vary in quality and don't have a standard way of doing things. Some may suppress the default linker paths for example, some may not. We have cases where we build libc in a different location than /usr/lib (e.g. for x32 ABI support in libx32) and many of the gnupg -config scripts have assumptions about the default linker search paths for example. We have a multilib setup that uses lib32 which your -config files don't cover. By comparison, pkg-config addresses our problems. It has a mechanism to specify if a sysroot is being used and knows to prepend paths with that if its set. It understands how to extract the default search paths from the toolchain so it knows which can be suppressed and which should not. We've had to teach one tool about these things and then it gets applied everywhere in a standard way. I understand you can't just drop -config scripts however allowing pkgconfig as an option would make the lives of those of us doing cross compiling much easier. Cheers, Richard From e1ven at e1ven.com Mon May 26 02:29:36 2014 From: e1ven at e1ven.com (Colin Davis) Date: Sun, 25 May 2014 20:29:36 -0400 Subject: Makefile change to fix my location compilation issue Message-ID: Good Morning, I've been running into some difficulty in compiling git-master of gnupg using OSX 10.9.3. I encountered various undefined symbols several times - I was able to work around them by editing the Makefile, and I've attached my changes here. I'm quite sure there's a better way to do this, but I thought I'd share my changes in case anyone else ran into the same problems. -CPD -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.patch Type: application/octet-stream Size: 2071 bytes Desc: not available URL: From e1ven at e1ven.com Mon May 26 09:28:28 2014 From: e1ven at e1ven.com (Colin Davis) Date: Mon, 26 May 2014 03:28:28 -0400 Subject: Makefile change to fix my location compilation issue In-Reply-To: References: Message-ID: Looks like attachments are stripped - adding the Makefile patch inline. >From 47d2d4ccf93f81fcb3f16081297babb0b70e6b0b Mon Sep 17 00:00:00 2001 From: Colin Davis Date: Sun, 25 May 2014 20:13:24 -0400 Subject: [PATCH] Makefile changes to explicitly include needed libraries --- common/Makefile.am | 4 ++-- g10/Makefile.am | 2 +- tools/Makefile.am | 2 +- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/common/Makefile.am b/common/Makefile.am index b955539..1aca055 100644 --- a/common/Makefile.am +++ b/common/Makefile.am @@ -185,7 +185,7 @@ endif module_maint_tests = t-helpfile t-b64 t-http -t_common_ldadd = libcommon.a ../gl/libgnu.a \ +t_common_ldadd = libcommon.a libcommon_a-init.o ../gl/libgnu.a \ $(LIBGCRYPT_LIBS) $(LIBASSUAN_LIBS) $(GPG_ERROR_LIBS) \ $(LIBINTL) $(LIBICONV) @@ -219,7 +219,7 @@ t_zb32_LDADD = $(t_common_ldadd) # http tests t_http_SOURCES = t-http.c -t_http_CFLAGS = $(t_common_cflags) $(LIBGNUTLS_CFLAGS) +t_http_CFLAGS = $(AM_CFLAGS) $(t_common_cflags) $(LIBGNUTLS_CFLAGS) t_http_LDADD = libcommontls.a $(t_common_ldadd) $(LIBGNUTLS_LIBS) $(DNSLIBS) # All programs should depend on the created libs. diff --git a/g10/Makefile.am b/g10/Makefile.am index ba68648..54c86c4 100644 --- a/g10/Makefile.am +++ b/g10/Makefile.am @@ -25,7 +25,7 @@ AM_CPPFLAGS = -I$(top_srcdir)/gl -I$(top_srcdir)/common \ include $(top_srcdir)/am/cmacros.am -AM_CFLAGS = $(LIBGCRYPT_CFLAGS) $(LIBASSUAN_CFLAGS) $(GPG_ERROR_CFLAGS) +AM_CFLAGS = $(KSBA_CFLAGS) $(LIBGCRYPT_CFLAGS) $(LIBASSUAN_CFLAGS) $(GPG_ERROR_CFLAGS) needed_libs = ../kbx/libkeybox.a $(libcommon) ../gl/libgnu.a diff --git a/tools/Makefile.am b/tools/Makefile.am index 946ae4a..045ddea 100644 --- a/tools/Makefile.am +++ b/tools/Makefile.am @@ -23,7 +23,7 @@ EXTRA_DIST = \ ccidmon.c ChangeLog-2011 gpg-connect-agent-w32info.rc -AM_CPPFLAGS = -I$(top_srcdir)/gl -I$(top_srcdir)/intl -I$(top_srcdir)/common +AM_CPPFLAGS = $(AM_CFLAGS) -I$(top_srcdir)/gl -I$(top_srcdir)/intl -I$(top_srcdir)/common include $(top_srcdir)/am/cmacros.am if HAVE_W32_SYSTEM -- 1.9.3 On Sun, May 25, 2014 at 8:29 PM, Colin Davis wrote: > Good Morning, > > I've been running into some difficulty in compiling git-master of gnupg > using OSX 10.9.3. > > I encountered various undefined symbols several times - I was able to work > around them by editing the Makefile, and I've attached my changes here. > > I'm quite sure there's a better way to do this, but I thought I'd share my > changes in case anyone else ran into the same problems. > > -CPD > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Mon May 26 17:35:28 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 26 May 2014 17:35:28 +0200 Subject: credit card donations Message-ID: <87k398zh6n.fsf@vigenere.g10code.de> Hi! due to the high charges Paypal takes for donations via their system and because Paypal is anyway not the Right Thing for privacy aware people, I started some work to accept standard credit card donations. I decided on Stripe as Payment processor due to their clean API and nice documentation. Stripe is different from PayPal in that our website needs to charge the card itself and not delegate the entire process to PP. To avoid storing or even receiving credit card numbers at gnupg.org, the ?checkout? method is used: The browser connects directly to Stripe and a Javascript asks you for the card details. Stripe then calls the CGI with a one-use-only token, representing the card information. The CGI at gnupg.org in turn connects payprocd (a local daemon) which performs the actual transaction using that token. The use of Javascript is a bit unfortunate but I feel safer doing it this way. Things probably need to be improved but I am confident enough to set it alive. Just in case you anyway want to donate to GnuPG with a credit card, you may now use https://gnupg.org/donate/ If you have any suggestion (apart from the ugly CSS), please report them here. The code is at git://git.gnupg.org/gnupg-doc.git (in particular cgi/ and web/donate/) and at git://git.gnupg.org/payproc.git Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From dominik at heidler.eu Mon May 26 17:51:57 2014 From: dominik at heidler.eu (Dominik Heidler) Date: Mon, 26 May 2014 17:51:57 +0200 Subject: credit card donations In-Reply-To: <87k398zh6n.fsf@vigenere.g10code.de> References: <87k398zh6n.fsf@vigenere.g10code.de> Message-ID: <5383631D.5080205@heidler.eu> Am 26.05.2014 17:35, schrieb Werner Koch: > https://gnupg.org/donate/ > > If you have any suggestion (apart from the ugly CSS), please report them > here. It would be nice to have text-labels (so if you click on the text, the radiobox is selected): From wk at gnupg.org Mon May 26 20:49:12 2014 From: wk at gnupg.org (Werner Koch) Date: Mon, 26 May 2014 20:49:12 +0200 Subject: credit card donations In-Reply-To: <5383631D.5080205@heidler.eu> (Dominik Heidler's message of "Mon, 26 May 2014 17:51:57 +0200") References: <87k398zh6n.fsf@vigenere.g10code.de> <5383631D.5080205@heidler.eu> Message-ID: <87ppj0xtnb.fsf@vigenere.g10code.de> On Mon, 26 May 2014 17:51, dominik at heidler.eu said: > It would be nice to have text-labels (so if you click on the text, the > radiobox is selected): Didn't know that tag. Done. Thanks. Salam-Shalom, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From gniibe at fsij.org Fri May 30 15:21:24 2014 From: gniibe at fsij.org (NIIBE Yutaka) Date: Fri, 30 May 2014 22:21:24 +0900 Subject: gnupg 1.4 decryption with smartcard for anonymous recipient Message-ID: <1401456084.28909.2.camel@latx1.gniibe.org> Hello, While trying git-remote-gcrypt, I found different behaviors between gpg1.4 and gpg2.0. With gpg1.4: ------------------------ gcrypt: Decrypting manifest gpg: anonymous recipient; trying secret key 4CA7BABE ... gpg: sending command `SCD PKDECRYPT' to agent failed: ec=6.18 gpg: anonymous recipient; trying secret key 084239CF ... gpg: okay, we are the anonymous recipient. gpg: Signature made Fri May 30 15:59:25 2014 JST using RSA key ID 4CA7BABE gpg: Good signature from "NIIBE Yutaka " gpg: aka "NIIBE Yutaka " gcrypt: Failed to decrypt manifest! ------------------------ It fails because exit code is 2. With gpg2.0: ------------------------ gcrypt: Decrypting manifest gpg: anonymous recipient; trying secret key 4CA7BABE ... gpg: anonymous recipient; trying secret key 084239CF ... gpg: okay, we are the anonymous recipient. gpg: Signature made Fri May 30 15:59:25 2014 JST using RSA key ID 4CA7BABE gpg: Good signature from "NIIBE Yutaka " gpg: aka "NIIBE Yutaka " ------------------------ It gets success. 4CA7BABE is a primary key and 084239CF is a decryption subkey, and both are on smartcard. SCD PKDECRYPT results ERR for a primary key, but it should not count as an error, because it's on the trial decryption. Looking 2.0, here is a possible fix in 1.4. It works for me, (with git-remote-gcrypt). diff --git a/g10/cardglue.c b/g10/cardglue.c index 809b315..60dc6b6 100644 --- a/g10/cardglue.c +++ b/g10/cardglue.c @@ -1406,10 +1406,8 @@ agent_scd_pkdecrypt (const char *serialno, init_membuf (&data, 1024); snprintf (line, DIM(line)-1, "SCD PKDECRYPT %s", serialno); line[DIM(line)-1] = 0; - rc = test_transact (assuan_transact (app->assuan_ctx, line, - membuf_data_cb, &data, - NULL, NULL, NULL, NULL), - "SCD PKDECRYPT"); + rc = assuan_transact (app->assuan_ctx, line, membuf_data_cb, &data, + NULL, NULL, NULL, NULL); if (rc) xfree (get_membuf (&data, &len)); else -- From wk at gnupg.org Fri May 30 19:27:22 2014 From: wk at gnupg.org (Werner Koch) Date: Fri, 30 May 2014 19:27:22 +0200 Subject: gnupg 1.4 decryption with smartcard for anonymous recipient In-Reply-To: <1401456084.28909.2.camel@latx1.gniibe.org> (NIIBE Yutaka's message of "Fri, 30 May 2014 22:21:24 +0900") References: <1401456084.28909.2.camel@latx1.gniibe.org> Message-ID: <87vbsnuqh1.fsf@vigenere.g10code.de> On Fri, 30 May 2014 15:21, gniibe at fsij.org said: > Looking 2.0, here is a possible fix in 1.4. It works for me, (with > git-remote-gcrypt). I would suggest to make it more explicit. Best would be to detect the try-all-secret case and suppress the error message. Something like this (not at all tested): diff --git a/g10/cardglue.c b/g10/cardglue.c index 809b315..993b6c8 100644 --- a/g10/cardglue.c +++ b/g10/cardglue.c @@ -357,15 +357,21 @@ agent_release_card_info (struct agent_card_info_s *info) /* Print an error message for a failed assuan_transact and return a gpg error code. No error is printed if RC is 0. */ static gpg_error_t -test_transact (int rc, const char *command) +test_transact2 (int rc, const char *command, int silent) { if (!rc) return 0; + if (!silent) log_error ("sending command `%s' to agent failed: %s\n", command, assuan_strerror (rc)); return gpg_error (GPG_ERR_CARD); } +static gpg_error_t +test_transact (int rc, const char *command) +{ + return test_transact2 (rc, command, 0); +} /* Try to open a card using an already running agent. Prepare a proper application context and return it. */ @@ -1370,6 +1376,7 @@ agent_scd_pksign (const char *serialno, int hashalgo, int agent_scd_pkdecrypt (const char *serialno, const unsigned char *indata, size_t indatalen, + int silent, unsigned char **r_buf, size_t *r_buflen) { struct pincb_parm_s parm; @@ -1406,10 +1413,10 @@ agent_scd_pkdecrypt (const char *serialno, init_membuf (&data, 1024); snprintf (line, DIM(line)-1, "SCD PKDECRYPT %s", serialno); line[DIM(line)-1] = 0; - rc = test_transact (assuan_transact (app->assuan_ctx, line, + rc = assuan_transact (app->assuan_ctx, line, membuf_data_cb, &data, - NULL, NULL, NULL, NULL), - "SCD PKDECRYPT"); + NULL, NULL, NULL, NULL); + rc = test_transact2 (rc, "SCD PKDECRYPT", silent); if (rc) xfree (get_membuf (&data, &len)); else diff --git a/g10/pubkey-enc.c b/g10/pubkey-enc.c index 51b5c55..6f42576 100644 --- a/g10/pubkey-enc.c +++ b/g10/pubkey-enc.c @@ -36,7 +36,7 @@ #include "cardglue.h" static int get_it( PKT_pubkey_enc *k, - DEK *dek, PKT_secret_key *sk, u32 *keyid ); + DEK *dek, PKT_secret_key *sk, u32 *keyid, int silent); /* check that the given algo is mentioned in one of the valid user IDs */ @@ -80,7 +80,7 @@ get_session_key( PKT_pubkey_enc *k, DEK *dek ) sk = xmalloc_clear( sizeof *sk ); sk->pubkey_algo = k->pubkey_algo; /* we want a pubkey with this algo*/ if( !(rc = get_seckey( sk, k->keyid )) ) - rc = get_it( k, dek, sk, k->keyid ); + rc = get_it( k, dek, sk, k->keyid, 0 ); } else { /* anonymous receiver: Try all available secret keys */ void *enum_context = NULL; @@ -114,7 +114,7 @@ get_session_key( PKT_pubkey_enc *k, DEK *dek ) once */ if( !rc ) { - rc = get_it( k, dek, sk, keyid ); + rc = get_it( k, dek, sk, keyid, 1 ); /* Successfully checked the secret key (either it was a card, had no passphrase, or had the right passphrase) but couldn't decrypt the session key, @@ -145,7 +145,8 @@ get_session_key( PKT_pubkey_enc *k, DEK *dek ) static int -get_it( PKT_pubkey_enc *enc, DEK *dek, PKT_secret_key *sk, u32 *keyid ) +get_it( PKT_pubkey_enc *enc, DEK *dek, PKT_secret_key *sk, u32 *keyid, + int silent) { int rc; MPI plain_dek = NULL; @@ -170,7 +171,8 @@ get_it( PKT_pubkey_enc *enc, DEK *dek, PKT_secret_key *sk, u32 *keyid ) if (!indata) BUG (); - rc = agent_scd_pkdecrypt (snbuf, indata, indatalen, &rbuf, &rbuflen); + rc = agent_scd_pkdecrypt (snbuf, indata, indatalen, silent, + &rbuf, &rbuflen); xfree (snbuf); xfree (indata); if (rc) -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.