-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05/07/2014 05:04 PM, Werner Koch wrote: > On Tue, 6 May 2014 19:45, > kristian.fiskerstr...@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 || <no SNI> 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----- _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel