From Venkata.Chaitanya at GainSpan.com Tue Jul 1 08:16:21 2014 From: Venkata.Chaitanya at GainSpan.com (Venkata Chaitanya) Date: Mon, 30 Jun 2014 23:16:21 -0700 Subject: [gnutls-help] TLS renegotiation Message-ID: <3582894D7E3C1141A7D0D3132B8EC38B37A62B9F80@GS-EX01.GainSpan.LAN> Hi, Can any one assist me in congiguring renegotiation in gnutls server. Thanks, Chaitanya -------------- next part -------------- An HTML attachment was scrubbed... URL: From Venkata.Chaitanya at GainSpan.com Wed Jul 2 11:48:37 2014 From: Venkata.Chaitanya at GainSpan.com (Venkata Chaitanya) Date: Wed, 2 Jul 2014 02:48:37 -0700 Subject: [gnutls-help] FW: TLS renegotiation In-Reply-To: <3582894D7E3C1141A7D0D3132B8EC38B37A62B9F80@GS-EX01.GainSpan.LAN> References: <3582894D7E3C1141A7D0D3132B8EC38B37A62B9F80@GS-EX01.GainSpan.LAN> Message-ID: <3582894D7E3C1141A7D0D3132B8EC38B37A62BA070@GS-EX01.GainSpan.LAN> Hi, Can any one assist me in congiguring renegotiation in gnutls server. Thanks, Chaitanya From: Gnutls-help [mailto:gnutls-help-bounces at lists.gnutls.org] On Behalf Of Venkata Chaitanya Sent: 01 July 2014 11:46 To: Gnutls-help at lists.gnutls.org Subject: [gnutls-help] TLS renegotiation Hi, Can any one assist me in congiguring renegotiation in gnutls server. Thanks, Chaitanya -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ATT00001..txt URL: From mpg at polarssl.org Fri Jul 11 02:33:46 2014 From: mpg at polarssl.org (=?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?=) Date: Fri, 11 Jul 2014 02:33:46 +0200 Subject: [gnutls-help] Forcing IPv4 with gnutls-cli? Message-ID: <53BF30EA.9010700@polarssl.org> Hi, Assume I want to connect to a DTLS server on localhost, that listens only in IPv4. On IPv6-capable systems, localhost also resolves as ::1 and this is the first address gnutls-cli tries. Unfortunately, with UDP it cannot detect that no-one is listening on the other side, so it keeps trying to resend it ClientHello to ::1 until it times out and exits with a failing status. I can force the use of IPv4 by specifying the host as "127.0.0.1" instead of "localhost" but then certificate validation fails. (Of course the use of localhost here is only an example, the same issue arises with any host whose name resolves to an IPv6 address too, but where the DTLS server only listens in IPv4.) I looked in the man page for one of the following options which would solve my problem, but failed to find them. 1. Ability for force IPv4 or IPv6. 2. Ability to specify separately a name for certificate validation and an address for the actual connection. Am I missing something obvious? Thanks in advance, Manuel. PS: now I'm looking into --tofu to work around the problem. Is there a way to specify an alternative "known_hosts" file? From dkg at fifthhorseman.net Fri Jul 11 08:09:27 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 11 Jul 2014 02:09:27 -0400 Subject: [gnutls-help] Forcing IPv4 with gnutls-cli? In-Reply-To: <53BF30EA.9010700@polarssl.org> References: <53BF30EA.9010700@polarssl.org> Message-ID: <53BF7F97.1020908@fifthhorseman.net> On 07/10/2014 08:33 PM, Manuel P?gouri?-Gonnard wrote: > Assume I want to connect to a DTLS server on localhost, that listens only in > IPv4. On IPv6-capable systems, localhost also resolves as ::1 and this is the > first address gnutls-cli tries. Unfortunately, with UDP it cannot detect that > no-one is listening on the other side, so it keeps trying to resend it > ClientHello to ::1 until it times out and exits with a failing status. > > I can force the use of IPv4 by specifying the host as "127.0.0.1" instead of > "localhost" but then certificate validation fails. > > (Of course the use of localhost here is only an example, the same issue arises > with any host whose name resolves to an IPv6 address too, but where the DTLS > server only listens in IPv4.) > > I looked in the man page for one of the following options which would solve my > problem, but failed to find them. > > 1. Ability for force IPv4 or IPv6. brainstorming features here: * ability to use an arbitrary file descriptor for the transport instead of opening a TCP connection directly would be nice, and ultimately more flexible as a debugging tool > 2. Ability to specify separately a name for certificate validation and an > address for the actual connection. I think we have at least six different possible places where the hostname is possibly used: 0) name for address lookup for TCP/UDP 1) name for DANE TLSA lookup 2) name to include in SNI 3) name to verify against X.509 certificate 4) name to verify against OpenPGP certificate 5) name to look up/store in TOFU known_hosts file For the sake of sanity of the interface, we probably want to conflate several of these, but it might be worth thinking through the tradeoffs. > Am I missing something obvious? > > Thanks in advance, > Manuel. > > PS: now I'm looking into --tofu to work around the problem. Is there a way to > specify an alternative "known_hosts" file? based on lib/verify-tofu.c and lib/system.c, it looks like the file will always be named "known_hosts" and it will be within $HOME/.gnutls/ on unix-derived systems. I suppose you could modify $HOME but that doesn't sound very satisfying. Nikos, i note that the functions around this all use snprintf and are generally limited to PATH_MAX, without verifying that snprintf returns a sensible value. I worry that for very large values of $HOME, this might produce some weird behavior, but i haven't been able to coax it into anything concrete yet. Maybe it's worth having a look and thinking through what the consequences would be for a very long $HOME? Regards, --dkg --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From mpg at polarssl.org Mon Jul 14 12:54:37 2014 From: mpg at polarssl.org (=?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?=) Date: Mon, 14 Jul 2014 12:54:37 +0200 Subject: [gnutls-help] RSA-PSK SSLv3 interop issues Message-ID: <53C3B6ED.8000303@polarssl.org> Hi, I recently noticed that PolarSSL and GnuTLS fail to interop when using RSA-PSK ciphersuites with SSLv3. The reason is, PolarSSL uses EncryptPreMasterSecret without initial length bytes, as was done in SSLv3, but GnuTLS wants the length bytes (as in TLS 1.x). RFC 4279 says: The EncryptedPreMasterSecret field sent from the client to the server contains a 2-byte version number and a 46-byte random value, encrypted using the server's RSA public key as described in Section 7.4.7.1 of [RFC2246] So it refers to RFC 2246 which defines TLS 1.0, which was current when RFC 4279 was published, but doesn't say anything about previous versions. There are (at least) two ways to interpret this silence: 1. Do as in TLS 1.0 even with older version. 2. Encode EncryptedPreMasterSecret as is usually done in the active version. GnuTLS does (1) and PolarSSL does (2), hence the interop issue. Of course a third way to interpret this silence might be to limit RSA-PSK suites to TLS 1.x where there is no possible ambiguity. Before taking any action, I wanted to check with you. What's your opinion on this matter? Manuel. PS: according to Wikipedia's comparison of TLS implementations, we'd be the only libraries implementing RSA-PSK. From frankspears at rambler.ru Sat Jul 19 01:22:11 2014 From: frankspears at rambler.ru (Frank Spears) Date: Sat, 19 Jul 2014 03:22:11 +0400 Subject: [gnutls-help] compiling GnuTLS under MSYS/MinGW Message-ID: <1405725731.44370.4774.16804@mail.rambler.ru> hi, trying to compile GnuTLS on Windows under MSYS/MinGW. the latest version 3.3.5 as well as version 3.2.9 fail to configure with the following error message: checking for NETTLE... configure: error: *** *** Libnettle 2.7 was not found. libnettle-2.7.1 is installed on the system and GnuTLS version 3.1.25 finds it and configures with no error. however, version 3.1.25 fails to build during the make process with the following messages: CC vsnprintf.lo CCLD libgnu.la /bin/grep: /home/keith/staged/mingw32/lib/libiconv.la: No such file or directory /bin/sed: can't read /home/keith/staged/mingw32/lib/libiconv.la: No such file or directory libtool: link: `/home/keith/staged/mingw32/lib/libiconv.la' is not a valid libtool archive make[4]: *** [libgnu.la] Error 1 make[4]: Leaving directory `/f/temp/sim/gnutls-3.1.25/gl' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/f/temp/sim/gnutls-3.1.25/gl' make[2]: *** [all] Error 2 make[2]: Leaving directory `/f/temp/sim/gnutls-3.1.25/gl' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/f/temp/sim/gnutls-3.1.25' make: *** [all] Error 2 libiconv.a and libiconv.dll.a are installed on the system under lib but i do not have a libiconv.la and i have no idea where "keith" came from. using --disable-shared did not help. as for libnettle and GnuTLS version 3.2.9 or later, i found no useful information in the config.log except perhaps that pkg-config is not found. can anyone provide me with a clue? Frank Spears. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpg at polarssl.org Mon Jul 21 18:08:48 2014 From: mpg at polarssl.org (=?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?=) Date: Mon, 21 Jul 2014 18:08:48 +0200 Subject: [gnutls-help] Ciphersuite minimal version inconsistency? In-Reply-To: References: <5310AD63.8070308@polarssl.org> <5310D8C6.2090807@gnutls.org> <531EE26F.1020101@polarssl.org> Message-ID: <53CD3B10.7040308@polarssl.org> Hi, sorry for reviving an old discussion. On 11/03/2014 13:02, Nikos Mavrogiannopoulos wrote: > Actually I was wrong in allowing them. SSL 3.0 uses a special MAC > construction that isn't defined for SHA256 or better, and there is no > authority to extend that definition. I'll revert that choice on the > next bug fix release. > I'm afraid you forgot to change back the minimum version to TLS 1.0 for some ciphersuites using SHA-2 : % gnutls-cli --version | head -n 1 gnutls-cli 3.3.5 % gnutls-cli --priority EXPORT:+NULL:+MD5:+PSK:+DHE-PSK:+ECDHE-PSK:+RSA-PSK --list | grep 'SHA[23].*SSL3' TLS_RSA_NULL_SHA256 0x00, 0x3b SSL3.0 TLS_DHE_DSS_CAMELLIA_256_CBC_SHA256 0x00, 0xc3 SSL3.0 TLS_PSK_NULL_SHA256 0x00, 0xb0 SSL3.0 TLS_PSK_NULL_SHA384 0x00, 0xb1 SSL3.0 TLS_DHE_PSK_NULL_SHA256 0x00, 0xb4 SSL3.0 TLS_DHE_PSK_NULL_SHA384 0x00, 0xb5 SSL3.0 TLS_ECDHE_PSK_NULL_SHA256 0xc0, 0x3a SSL3.0 TLS_ECDHE_PSK_NULL_SHA384 0xc0, 0x3b SSL3.0 TLS_RSA_PSK_NULL_SHA256 0x00, 0xb8 SSL3.0 TLS_RSA_PSK_NULL_SHA384 0x00, 0xb9 SSL3.0 (I'm not claiming the above list is complete.) Regards, Manuel. From nmav at gnutls.org Tue Jul 22 13:05:34 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 22 Jul 2014 13:05:34 +0200 Subject: [gnutls-help] Ciphersuite minimal version inconsistency? In-Reply-To: <53CD3B10.7040308@polarssl.org> References: <5310AD63.8070308@polarssl.org> <5310D8C6.2090807@gnutls.org> <531EE26F.1020101@polarssl.org> <53CD3B10.7040308@polarssl.org> Message-ID: On Mon, Jul 21, 2014 at 6:08 PM, Manuel P?gouri?-Gonnard wrote: > Hi, > sorry for reviving an old discussion. > On 11/03/2014 13:02, Nikos Mavrogiannopoulos wrote: >> Actually I was wrong in allowing them. SSL 3.0 uses a special MAC >> construction that isn't defined for SHA256 or better, and there is no >> authority to extend that definition. I'll revert that choice on the >> next bug fix release. > I'm afraid you forgot to change back the minimum version to TLS 1.0 for some > ciphersuites using SHA-2 : Thank you for reporting that. That should have now been corrected in master. regards, Nikos From nmav at gnutls.org Tue Jul 22 13:09:52 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 22 Jul 2014 13:09:52 +0200 Subject: [gnutls-help] Forcing IPv4 with gnutls-cli? In-Reply-To: <53BF30EA.9010700@polarssl.org> References: <53BF30EA.9010700@polarssl.org> Message-ID: On Fri, Jul 11, 2014 at 2:33 AM, Manuel P?gouri?-Gonnard wrote: > Hi, > Assume I want to connect to a DTLS server on localhost, that listens only in > IPv4. On IPv6-capable systems, localhost also resolves as ::1 and this is the > first address gnutls-cli tries. Unfortunately, with UDP it cannot detect that > no-one is listening on the other side, so it keeps trying to resend it > ClientHello to ::1 until it times out and exits with a failing status. > I can force the use of IPv4 by specifying the host as "127.0.0.1" instead of > "localhost" but then certificate validation fails. Most probably we need an option to separately set the hostname and the IP to connect to. Not in my immediate plans to add, but if there is a patch for that, I'll apply it. regards, Nikos From nmav at gnutls.org Tue Jul 22 13:17:23 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 22 Jul 2014 13:17:23 +0200 Subject: [gnutls-help] Forcing IPv4 with gnutls-cli? In-Reply-To: <53BF7F97.1020908@fifthhorseman.net> References: <53BF30EA.9010700@polarssl.org> <53BF7F97.1020908@fifthhorseman.net> Message-ID: On Fri, Jul 11, 2014 at 8:09 AM, Daniel Kahn Gillmor wrote: > based on lib/verify-tofu.c and lib/system.c, it looks like the file will > always be named "known_hosts" and it will be within $HOME/.gnutls/ on > unix-derived systems. I suppose you could modify $HOME but that doesn't > sound very satisfying. gnutls_verify_stored_pubkey, allows specifying an alternative filename (through db_name), or even a database using the tdb argument. gnutls-cli doesn't allow setting that option but a small patch could allow setting that file. > Nikos, i note that the functions around this all use snprintf and are > generally limited to PATH_MAX, without verifying that snprintf returns a > sensible value. I worry that for very large values of $HOME, this might > produce some weird behavior, but i haven't been able to coax it into > anything concrete yet. Maybe it's worth having a look and thinking > through what the consequences would be for a very long $HOME? I think that the limitation can be lifted by using asprintf() or similar. If there is a patch that lifts that limitation in a portable way I'll apply it. regards, Nikos From nmav at gnutls.org Tue Jul 22 13:27:23 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Tue, 22 Jul 2014 13:27:23 +0200 Subject: [gnutls-help] RSA-PSK SSLv3 interop issues In-Reply-To: <53C3B6ED.8000303@polarssl.org> References: <53C3B6ED.8000303@polarssl.org> Message-ID: On Mon, Jul 14, 2014 at 12:54 PM, Manuel P?gouri?-Gonnard wrote: > Hi, > I recently noticed that PolarSSL and GnuTLS fail to interop when using RSA-PSK > ciphersuites with SSLv3. The reason is, PolarSSL uses EncryptPreMasterSecret > without initial length bytes, as was done in SSLv3, but GnuTLS wants the length > bytes (as in TLS 1.x). > RFC 4279 says: > > The EncryptedPreMasterSecret field sent from the client to the server > contains a 2-byte version number and a 46-byte random value, > encrypted using the server's RSA public key as described in Section > 7.4.7.1 of [RFC2246] > So it refers to RFC 2246 which defines TLS 1.0, which was current when RFC 4279 > was published, but doesn't say anything about previous versions. There are (at > least) two ways to interpret this silence: > 1. Do as in TLS 1.0 even with older version. > 2. Encode EncryptedPreMasterSecret as is usually done in the active version. > GnuTLS does (1) and PolarSSL does (2), hence the interop issue. Of course a > third way to interpret this silence might be to limit RSA-PSK suites to TLS 1.x > where there is no possible ambiguity. > Before taking any action, I wanted to check with you. What's your opinion on > this matter? I think that limiting RSA-PSK to TLS 1.0 or later is the best option, and I'll do that in 3.3.x. > PS: according to Wikipedia's comparison of TLS implementations, we'd be the only > libraries implementing RSA-PSK. I don't particularly like the properties of the RSA-PSK key exchange. It is only in gnutls because it was contributed. If I had a choice I'd prefer something that used signing over DHE-PSK. regards, Nikos From mpg at polarssl.org Tue Jul 22 13:34:10 2014 From: mpg at polarssl.org (=?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?=) Date: Tue, 22 Jul 2014 13:34:10 +0200 Subject: [gnutls-help] RSA-PSK SSLv3 interop issues In-Reply-To: References: <53C3B6ED.8000303@polarssl.org> Message-ID: <53CE4C32.8070307@polarssl.org> On 22/07/2014 13:27, Nikos Mavrogiannopoulos wrote: > I think that limiting RSA-PSK to TLS 1.0 or later is the best option, > and I'll do that in 3.3.x. > I agree. That's what we'll do for the next PolarSSL release too. Regards, Manuel. From nmav at gnutls.org Wed Jul 23 09:31:37 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 23 Jul 2014 09:31:37 +0200 Subject: [gnutls-help] gnutls 3.2.16 Message-ID: <1406100697.22361.0.camel@nomad.lan> Hello, I've just released gnutls 3.2.16. This is a bugfix release on the current stable branch. * Version 3.2.16 (released 2014-07-23) ** libgnutls: Do not call the post client hello callback twice when resuming using session tickets. ** libgnutls: When the decoding of a printable DN element fails, then treat it as unknown and print its hex value rather than failing. That works around an issue in a TURKTRST root certificate which improperly encodes the X520countryName element. ** libgnutls: IP addresses are printed using inet_ntop() when available. ** libgnutls: gnutls_x509_crt_check_hostname will also check IP addresses and match documented behavior. Reported by David Woodhouse. ** libgnutls: Fixed PKCS #11 ECDSA key generation. ** p11tool: use GNUTLS_SO_PIN to read the security officer's PIN if set. ** p11tool: will not implicitly enable so-login for certain types of objects. That avoids issues with tokens that require different login types. ** API and ABI modifications: No changes since last version. Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.16.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.16.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.16.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.2/gnutls-3.2.16.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From nmav at gnutls.org Wed Jul 23 09:33:08 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 23 Jul 2014 09:33:08 +0200 Subject: [gnutls-help] gnutls 3.3.6 Message-ID: <1406100788.22361.2.camel@nomad.lan> Hello, I've just released gnutls 3.3.6. This release adds new features, and fixes bugs on the next-stable branch. * Version 3.3.6 (released 2014-07-23) ** libgnutls: Use inet_ntop to print IP addresses when available ** libgnutls: gnutls_x509_crt_check_hostname and friends will also check IP addresses, and match documented behavior. Reported by David Woodhouse. ** libgnutls: DSA key generation in FIPS140-2 mode doesn't allow 1024 bit parameters. ** libgnutls: fixed issue in gnutls_pkcs11_reinit() which prevented tokens being usable after a reinitialization. ** libgnutls: fixed PKCS #11 private key operations after a fork. ** libgnutls: fixed PKCS #11 ECDSA key generation. ** libgnutls: The GNUTLS_CPUID_OVERRIDE environment variable can be used to explicitly enable/disable the use of certain CPU capabilities. Note that CPU detection cannot be overriden, i.e., VIA options cannot be enabled on an Intel CPU. The currently available options are: 0x1: Disable all run-time detected optimizations 0x2: Enable AES-NI 0x4: Enable SSSE3 0x8: Enable PCLMUL 0x100000: Enable VIA padlock 0x200000: Enable VIA PHE 0x400000: Enable VIA PHE SHA512 ** libdane: added dane_query_to_raw_tlsa(); patch by Simon Arlott. ** p11tool: use GNUTLS_SO_PIN to read the security officer's PIN if set. ** p11tool: ask for label when one isn't provided. ** p11tool: added --batch parameter to disable any interactivity. ** p11tool: will not implicitly enable so-login for certain types of objects. That avoids issues with tokens that require different login types. ** certtool/p11tool: Added the --curve parameter which allows to explicitly specify the curve to use. ** API and ABI modifications: gnutls_certificate_set_x509_trust_dir: Added gnutls_x509_trust_list_add_trust_dir: Added Getting the Software ==================== GnuTLS may be downloaded directly from . A list of GnuTLS mirrors can be found at . Here are the XZ and LZIP compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.6.tar.xz ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.6.tar.lz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.6.tar.xz.sig ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.6.tar.lz.sig Note that it has been signed with my openpgp key: pub 3104R/96865171 2008-05-04 [expires: 2028-04-29] uid Nikos Mavrogiannopoulos gnutls.org> uid Nikos Mavrogiannopoulos gmail.com> sub 2048R/9013B842 2008-05-04 [expires: 2018-05-02] sub 2048R/1404A91D 2008-05-04 [expires: 2018-05-02] regards, Nikos From me at tbizzy.com Thu Jul 24 17:54:29 2014 From: me at tbizzy.com (meat bizzy) Date: Thu, 24 Jul 2014 11:54:29 -0400 Subject: [gnutls-help] Cipher testing Message-ID: Hello, Is there anyway using the gnutls-cli/server tools to force a certain cipher to be used? In openssl you can specify the cipher option on the client with --cipher option. The goal is I want to test specific ciphers one at a time. Thanks, -Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpg at polarssl.org Fri Jul 25 09:34:31 2014 From: mpg at polarssl.org (=?ISO-8859-1?Q?Manuel_P=E9gouri=E9-Gonnard?=) Date: Fri, 25 Jul 2014 09:34:31 +0200 Subject: [gnutls-help] Cipher testing In-Reply-To: References: Message-ID: <53D20887.5020703@polarssl.org> Hi, On 24/07/2014 17:54, meat bizzy wrote: > Is there anyway using the gnutls-cli/server tools to force a certain cipher > to be used? > You can use priority strings such as +VERS-TLS1.2:+ECDHE-ECDSA:+AES-128-GCM:+AEAD It's rather easy to generate those programmatically from the IANA name. Manuel. From nmav at gnutls.org Mon Jul 28 15:22:03 2014 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 28 Jul 2014 15:22:03 +0200 Subject: [gnutls-help] gnutls 3.2.16 mingw-w64 issue In-Reply-To: References: Message-ID: On Sun, Jul 27, 2014 at 4:22 PM, XhmikosR wrote: > Hi. > While trying to build gnutls 3.2.16 under MSYS with mingw-w64 I keep getting > the following errors > https://gist.github.com/XhmikosR/b3beef214de6c103ccfa > Note that 3.2.15 compiles fine on the same system. Please use the mailing lists for any questions on gnutls. It seems inet_aton and pton are not available in windows. I've committed a work around at: https://gitorious.org/gnutls/gnutls/commit/410970f8777f2fe7a421e94999e542d023f35229 regards, Nikos