From m+gnutls at thi.eu.com Tue Feb 2 11:23:20 2016 From: m+gnutls at thi.eu.com (Mathieu Chouquet-Stringer) Date: Tue, 2 Feb 2016 11:23:20 +0100 Subject: [gnutls-help] gnutls_record_send says it sent more than I told it to!? Message-ID: <20160202102320.GA30698@bosco> Hello, I've coded an application in C and I use gnutls version 3.4.8 (3.4.8-1 on Fedora 23 x86_64). My program is just a TLS front end for some of my applications which don't know how to speak TLS. I don't use threads but use epoll to manage all active sessions. I've been trying to diagnose a bug and as such I've added a bunch of printf all around the code. I have a function that does the following when epoll says there something to read: received = recv(con->fd, buffer, con->peer->rec_size); if (received > 0) { wrote = gnutls_record_send(con->peer->session, buffer, received); if (wrote == GNUTLS_E_INTERRUPTED || wrote == GNUTLS_E_AGAIN) return 1; if (wrote > received) fprintf(stderr, "BUG at %d: wrote %ld, received: %ld\n", __LINE__, wrote, received); } else { /* do something else here */ } rec_size is basically <= 16k and <= to what gnutls_record_get_max_size returned. Everyonce in a while, the fprintf shows me this: BUG at 661: wrote 10380, received: 10364 BUG at 661: wrote 16384, received: 15092 BUG at 661: wrote 16384, received: 11376 BUG at 661: wrote 16384, received: 11400 BUG at 661: wrote 16384, received: 11400 BUG at 661: wrote 6892, received: 6780 BUG at 661: wrote 6892, received: 6780 I haven't managed to understand how to trigger it and I'm really curious why this could happen... Any idea or pointer would be welcome? -- Mathieu Chouquet-Stringer m+gnutls at thi.eu.com The sun itself sees not till heaven clears. -- William Shakespeare -- From n.mavrogiannopoulos at gmail.com Tue Feb 2 18:34:26 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Tue, 02 Feb 2016 18:34:26 +0100 Subject: [gnutls-help] gnutls_record_send says it sent more than I told it to!? In-Reply-To: <20160202102320.GA30698@bosco> References: <20160202102320.GA30698@bosco> Message-ID: <1454434466.1876.2.camel@gmail.com> On Tue, 2016-02-02 at 11:23 +0100, Mathieu Chouquet-Stringer wrote: > Hello, > > I've coded an application in C and I use gnutls version 3.4.8 (3.4.8 > -1 > on Fedora 23 x86_64). > > My program is just a TLS front end for some of my applications which > don't know how to speak TLS. > > I don't use threads but use epoll to manage all active sessions. > > I've been trying to diagnose a bug and as such I've added a bunch of > printf all around the code. > > I have a function that does the following when epoll says there > something to read: > > received = recv(con->fd, buffer, con->peer->rec_size); > > if (received > 0) { > wrote = gnutls_record_send(con->peer->session, > buffer, received); > if (wrote == GNUTLS_E_INTERRUPTED || wrote == > GNUTLS_E_AGAIN) > return 1; > if (wrote > received) > fprintf(stderr, "BUG at %d: wrote %ld, > received: %ld\n", > __LINE__, wrote, received); > } else { > /* do something else here */ > } > > rec_size is basically <= 16k and <= to what > gnutls_record_get_max_size > returned. > > Everyonce in a while, the fprintf shows me this: > BUG at 661: wrote 10380, received: 10364 > BUG at 661: wrote 16384, received: 15092 > BUG at 661: wrote 16384, received: 11376 > BUG at 661: wrote 16384, received: 11400 > BUG at 661: wrote 16384, received: 11400 > BUG at 661: wrote 6892, received: 6780 > BUG at 661: wrote 6892, received: 6780 Could it be that you are resuming a previously interrupted send? If the previous send was interrupted and returned GNUTLS_E_AGAIN or GNUTLS_E_INTERRUPTED then it will be resumed on the next call, unless you call gnutls_record_discard_queued(). regards, Nikos From m+gnutls at thi.eu.com Tue Feb 2 19:02:32 2016 From: m+gnutls at thi.eu.com (Mathieu Chouquet-Stringer) Date: Tue, 2 Feb 2016 19:02:32 +0100 Subject: [gnutls-help] gnutls_record_send says it sent more than I told it to!? In-Reply-To: <1454434466.1876.2.camel@gmail.com> References: <20160202102320.GA30698@bosco> <1454434466.1876.2.camel@gmail.com> Message-ID: <20160202180232.GA30932@bosco> Hello Nikos, On Tue, Feb 02, 2016 at 06:34:26PM +0100, Nikos Mavrogiannopoulos wrote: > Could it be that you are resuming a previously interrupted send? If the > previous send was interrupted and returned GNUTLS_E_AGAIN or > GNUTLS_E_INTERRUPTED then it will be resumed on the next call, unless > you call gnutls_record_discard_queued(). Yes I guess the logic of my code is somewhat defective (TM). My issue is the following: because I use non blocking sockets (without threads), if gnutls_record_send ever returns GNUTLS_E_INTERRUPTED or GNUTLS_E_AGAIN, I can't busy loop until it works. If I do so, all other sessions will be stuck. Plus it appears if I kill the socket while I'm looping on gnutls_record_send, the loop will keep on being executed... Bottom line is I cannot do: do { sent = gnutls_record_send(...); } while (sent == GNUTLS_E_INTERRUPTED || sent == GNUTLS_E_AGAIN); So what I do is I queue the write for later: I ask epoll to tell me when I can actually write (EPOLLOUT) to the socket tied to that TLS session. Is that what I'm supposed to do? But before I get this event for that specific socket, I might have done other things (aka been reading or writing from/to other TLS sessions). So the question is as follow: does gnutls keep a private buffer per session (and direction, as in read buffer or write buffer) so when I call gnutls_record_send with data == NULL and size == 0, it does the right thing? Or can it get mixed up with other read/writes from different sessions? Reading the code, it looks that's what _gnutls_io_write_flush does but I'm not sure, because so far, I've haven't been able to make the whole "resume interrupted send" work. -- Mathieu Chouquet-Stringer m+gnutls at thi.eu.com The sun itself sees not till heaven clears. -- William Shakespeare -- From nmav at gnutls.org Wed Feb 3 09:04:51 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 03 Feb 2016 09:04:51 +0100 Subject: [gnutls-help] gnutls 3.3.21 Message-ID: <1454486691.2094.1.camel@gnutls.org> Hello, I've just released gnutls 3.3.21. This is a bug-fix release on the previous stable branch. * Version 3.3.21 (released 2016-02-03) ** libgnutls: Corrected ALPN protocol negotiation. Before GnuTLS would negotiate the last commonly supported protocol, rather than the first. Reported by Remi Denis-Courmont (#63). ** libgnutls: ARCFOUR (RC4) is no longer included in the default priorities list. It has to be explicitly enabled, e.g., with a string like "NORMAL:+ARCFOUR-128". The previous behavior can be restored using the flag --with-arcfour128 to configure. ** libgnutls: Corrected regression causes by incorrect fix in gnutls_x509_ext_export_key_usage() at 3.3.20 release. ** 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 compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.21.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.3/gnutls-3.3.21.tar.xz.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 Feb 3 09:24:40 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 03 Feb 2016 09:24:40 +0100 Subject: [gnutls-help] gnutls 3.4.9 Message-ID: <1454487880.2094.3.camel@gnutls.org> Hello, I've just released gnutls 3.4.9. This version fixes bugs in the current stable branch. * Version 3.4.9 (released 2016-02-03) ** libgnutls: Corrected ALPN protocol negotiation. Before GnuTLS would negotiate the last commonly supported protocol, rather than the first. Reported by Remi Denis-Courmont (#63). ** libgnutls: Tolerate empty DN fields in informational output functions. ** libgnutls: Corrected regression causes by incorrect fix in gnutls_x509_ext_export_key_usage() at 3.4.8 release. ** 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 compressed sources: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.9.tar.xz Here are OpenPGP detached signatures signed using key 0x96865171: ftp://ftp.gnutls.org/gcrypt/gnutls/v3.4/gnutls-3.4.9.tar.xz.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 n.mavrogiannopoulos at gmail.com Wed Feb 3 21:11:35 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Wed, 03 Feb 2016 21:11:35 +0100 Subject: [gnutls-help] gnutls_record_send says it sent more than I told it to!? In-Reply-To: <20160202180232.GA30932@bosco> References: <20160202102320.GA30698@bosco> <1454434466.1876.2.camel@gmail.com> <20160202180232.GA30932@bosco> Message-ID: <1454530295.1790.2.camel@gmail.com> On Tue, 2016-02-02 at 19:02 +0100, Mathieu Chouquet-Stringer wrote: > Hello Nikos, > > On Tue, Feb 02, 2016 at 06:34:26PM +0100, Nikos Mavrogiannopoulos > wrote: > > Could it be that you are resuming a previously interrupted send? If > > the > > previous send was interrupted and returned GNUTLS_E_AGAIN or > > GNUTLS_E_INTERRUPTED then it will be resumed on the next call, > > unless > > you call gnutls_record_discard_queued(). > > Yes I guess the logic of my code is somewhat defective (TM). > > My issue is the following: because I use non blocking sockets > (without > threads), if gnutls_record_send ever returns GNUTLS_E_INTERRUPTED or > GNUTLS_E_AGAIN, I can't busy loop until it works. If I do so, all > other > sessions will be stuck. Plus it appears if I kill the socket while > I'm > looping on gnutls_record_send, the loop will keep on being > executed... > > Bottom line is I cannot do: > > do { > sent = gnutls_record_send(...); > } while (sent == GNUTLS_E_INTERRUPTED || sent == > GNUTLS_E_AGAIN); > > So what I do is I queue the write for later: I ask epoll to tell me > when > I can actually write (EPOLLOUT) to the socket tied to that TLS > session. > Is that what I'm supposed to do? Yes. However, you must remember you had pending data already processed for that send() and you do not need to specify them again. > But before I get this event for that specific socket, I might have > done other things (aka been reading or writing from/to other TLS > sessions). Could it be that the data you intended to be send have been modified? > So the question is as follow: does gnutls keep a private buffer per > session (and direction, as in read buffer or write buffer) so when I > call gnutls_record_send with data == NULL and size == 0, it does the > right thing? Or can it get mixed up with other read/writes from > different sessions? Sessions are totally independent; they share no state except for the credentials structures which are read-only. regards, Nikos From m+gnutls at thi.eu.com Wed Feb 3 22:02:28 2016 From: m+gnutls at thi.eu.com (Mathieu Chouquet-Stringer) Date: Wed, 3 Feb 2016 22:02:28 +0100 Subject: [gnutls-help] gnutls_record_send says it sent more than I told it to!? In-Reply-To: <1454530295.1790.2.camel@gmail.com> References: <20160202102320.GA30698@bosco> <1454434466.1876.2.camel@gmail.com> <20160202180232.GA30932@bosco> <1454530295.1790.2.camel@gmail.com> Message-ID: <20160203210228.GA23846@bosco> On Wed, Feb 03, 2016 at 09:11:35PM +0100, Nikos Mavrogiannopoulos wrote: > Yes. However, you must remember you had pending data already processed > for that send() and you do not need to specify them again. Right, just call record_send with NULL and 0. > > But before I get this event for that specific socket, I might have > > done other things (aka been reading or writing from/to other TLS > > sessions). > > Could it be that the data you intended to be send have been modified? What do you mean? Something like: is my original data buffer untouched? Asked another way, do I have to maintain the integrity of my data between the EAGAIN call and the NULL/0? I think I have but I'll have to check in case I'm not supposed to touch that buffer until it's sent. > > So the question is as follow: does gnutls keep a private buffer per > > session (and direction, as in read buffer or write buffer) so when I > > call gnutls_record_send with data == NULL and size == 0, it does the > > right thing? Or can it get mixed up with other read/writes from > > different sessions? > > Sessions are totally independent; they share no state except for the > credentials structures which are read-only. Fair enough, thanks for clearing that out. -- Mathieu Chouquet-Stringer m+gnutls at thi.eu.com The sun itself sees not till heaven clears. -- William Shakespeare -- From jonetsu at teksavvy.com Wed Feb 3 23:37:26 2016 From: jonetsu at teksavvy.com (jonetsu) Date: Wed, 03 Feb 2016 17:37:26 -0500 Subject: [gnutls-help] Disabling use of elliptic curves at compile time Message-ID: <03bdcbc1708626a65b692bb8b071d9fa@teksavvy.com> Hello, Subject line basically says it.? Is it possible to disable the use of elliptic curves at compile time ? Thanks. From n.mavrogiannopoulos at gmail.com Fri Feb 5 01:16:07 2016 From: n.mavrogiannopoulos at gmail.com (Nikos Mavrogiannopoulos) Date: Fri, 05 Feb 2016 01:16:07 +0100 Subject: [gnutls-help] gnutls_record_send says it sent more than I told it to!? In-Reply-To: <20160203210228.GA23846@bosco> References: <20160202102320.GA30698@bosco> <1454434466.1876.2.camel@gmail.com> <20160202180232.GA30932@bosco> <1454530295.1790.2.camel@gmail.com> <20160203210228.GA23846@bosco> Message-ID: <1454631367.1811.1.camel@gmail.com> On Wed, 2016-02-03 at 22:02 +0100, Mathieu Chouquet-Stringer wrote: > > Could it be that the data you intended to be send have been > > modified? > > What do you mean? Something like: is my original data buffer > untouched? > Asked another way, do I have to maintain the integrity of my data > between the EAGAIN call and the NULL/0? I think I have but I'll have > to > check in case I'm not supposed to touch that buffer until it's sent. In no case you need to maintain the integrity of the data. However, if you resume a call and you input different data you will see discrepancy in send sizes, as the one you described. If you use NULL,0 as parameters you'll avoid that. regards, Nikos From will at damagesinc.net Fri Feb 5 00:53:13 2016 From: will at damagesinc.net (Will W.) Date: Thu, 4 Feb 2016 15:53:13 -0800 Subject: [gnutls-help] TLS cacertdir Message-ID: <9B756233-62D9-4C8E-8B4A-8A5FE5082293@damagesinc.net> I just complied gnutls 3.4.9 and I am getting an error. I have been going off this website, http://www.linuxfromscratch.org/blfs/view/svn/postlfs/gnutls.html ./configure --prefix=/usr --with-default-trust-store-file=/etc/ssl/certs/ca-certificates.crt --enable-openssl-compatibility TLS: warning: cacertdir not implemented for gnutls Has anyone seen this before? -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Mon Feb 8 13:35:37 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 8 Feb 2016 13:35:37 +0100 Subject: [gnutls-help] TLS cacertdir In-Reply-To: <9B756233-62D9-4C8E-8B4A-8A5FE5082293@damagesinc.net> References: <9B756233-62D9-4C8E-8B4A-8A5FE5082293@damagesinc.net> Message-ID: On Fri, Feb 5, 2016 at 12:53 AM, Will W. wrote: > I just complied gnutls 3.4.9 and I am getting an error. > I have been going off this website, > http://www.linuxfromscratch.org/blfs/view/svn/postlfs/gnutls.html > ./configure --prefix=/usr > --with-default-trust-store-file=/etc/ssl/certs/ca-certificates.crt > --enable-openssl-compatibility > TLS: warning: cacertdir not implemented for gnutls > Has anyone seen this before? This error message is not generated by gnutls. regards, Nikos From nmav at gnutls.org Mon Feb 8 13:36:37 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 8 Feb 2016 13:36:37 +0100 Subject: [gnutls-help] Disabling use of elliptic curves at compile time In-Reply-To: <03bdcbc1708626a65b692bb8b071d9fa@teksavvy.com> References: <03bdcbc1708626a65b692bb8b071d9fa@teksavvy.com> Message-ID: On Wed, Feb 3, 2016 at 11:37 PM, jonetsu wrote: > Hello, > Subject line basically says it. Is it possible to disable the use of elliptic curves at compile time ? What about --disable-ecdhe? From gnutls at wodny.org Tue Feb 9 16:06:00 2016 From: gnutls at wodny.org (Marcin Szewczyk) Date: Tue, 9 Feb 2016 16:06:00 +0100 Subject: [gnutls-help] Availability of gnutls.org over HTTPS Message-ID: <20160209150600.GB3060@orkisz> Hi, is there any particular reason for not having the gnutls.org available over HTTPS? I can imagine that a certificate has little meaning when one is downloading GnuTLS because the only reasonable approach is to verify the GPG signature on the source code. But what if I just want to have a quick look at the template file[1] for which it seems quite important not to serve it via a connection someone can hijack? There is also a possibility of embedding malicious content (e.g. JavaScript code) via a MitM attack and targeting some of gnutls.org visitors. [1] http://www.gnutls.org/manual/gnutls.html#Certtool_0027s-template-file-format -- Marcin Szewczyk http://wodny.org From nmav at gnutls.org Wed Feb 10 09:59:14 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 10 Feb 2016 09:59:14 +0100 Subject: [gnutls-help] Availability of gnutls.org over HTTPS In-Reply-To: <20160209150600.GB3060@orkisz> References: <20160209150600.GB3060@orkisz> Message-ID: On Tue, Feb 9, 2016 at 4:06 PM, Marcin Szewczyk wrote: > Hi, > is there any particular reason for not having the gnutls.org available > over HTTPS? The reason is that the server we are hosted did not support SSL/TLS. However, now I see that there is https available for www.gnupg.org. Werner could TLS be enabled for gnutls as well? regards, Nikos From cumt0516 at gmail.com Mon Feb 15 11:34:46 2016 From: cumt0516 at gmail.com (Shenme Hao) Date: Mon, 15 Feb 2016 18:34:46 +0800 Subject: [gnutls-help] How to compile gnutls-3.4.8 for iPhone simulator, iPhone devices Message-ID: Hi, I want to compile ffmpeg for iPhone with ssl support, I selected gnutls implementation for this purpose, so I have to compile gnutls library for iPhone simulator and iPhone, the iPhone simulator's architecture is i386 and iPhone's architecture is armv6, armv7, armv7s and so on. I don't know how to compile the gnutls on Mac OS X(EI Capitan) system for the target architecture(i386 and arm architectures). Can you help me? Thanks andy -------------- next part -------------- An HTML attachment was scrubbed... URL: From ron at flownet.com Sat Feb 20 22:04:05 2016 From: ron at flownet.com (Ron Garret) Date: Sat, 20 Feb 2016 13:04:05 -0800 Subject: [gnutls-help] Root certificates on a Mac Message-ID: <8593502D-E341-445B-A269-62D52C58A691@flownet.com> How can one configure gnutls to recognize the root certificates in the system keychain on OS X? Meta-question: I would have expected to be able to find the answer to this question with a Google search or by reading the docs. I cannot possibly be the first person to want to know the answer to this question. And yet the answer does not seem to be out there. The strings ?root certificate? and ?root ca? each occur exactly once in the documentation at http://gnutls.org/manual/gnutls.html, and neither of those is even remotely the answer to this question. So it seems my basic model of the world is somehow badly broken. What am I missing? How is someone supposed to figure out how to configure the root certs for gnutls? Thanks, rg From nmav at gnutls.org Mon Feb 22 19:57:00 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 22 Feb 2016 19:57:00 +0100 Subject: [gnutls-help] Root certificates on a Mac In-Reply-To: <8593502D-E341-445B-A269-62D52C58A691@flownet.com> References: <8593502D-E341-445B-A269-62D52C58A691@flownet.com> Message-ID: <1456167420.13252.14.camel@gnutls.org> On Sat, 2016-02-20 at 13:04 -0800, Ron Garret wrote: > How can one configure gnutls to recognize the root certificates in > the system keychain on OS X? > > Meta-question: I would have expected to be able to find the answer to > this question with a Google search or by reading the docs. I cannot > possibly be the first person to want to know the answer to this > question. And yet the answer does not seem to be out there. The > strings ?root certificate? and ?root ca? each occur exactly once in > the documentation at http://gnutls.org/manual/gnutls.html, and > neither of those is even remotely the answer to this question. So it > seems my basic model of the world is somehow badly broken. What am I > missing? How is someone supposed to figure out how to configure the > root certs for gnutls? There is no support for MacOSX in gnutls_certificate_set_x509_system_trust(). There are some 3rd party packages of gnutls for that system so maybe they setup the certificates via ./configure. Otherwise, someone would have to contribute that code. regards, Nikos From rick at openfortress.nl Mon Feb 22 21:19:10 2016 From: rick at openfortress.nl (Rick van Rein) Date: Mon, 22 Feb 2016 21:19:10 +0100 Subject: [gnutls-help] Root certificates on a Mac In-Reply-To: <8593502D-E341-445B-A269-62D52C58A691@flownet.com> References: <8593502D-E341-445B-A269-62D52C58A691@flownet.com> Message-ID: <56CB6D3E.9060202@openfortress.nl> Hi Ron, I approached your question from the other side, namely Mac OS X documentation. Many of the graphical facilities on Mac OS X are also available on the cmdline, including the "security" command that lets you: security dump-trust-settings > /tmp/a.txt security trust-settings-export /tmp/b.txt Either or both of these two files could help you with your quest. GnuTLS is a product that stands on its own, I suppose, so you may need to find a packager/integrator who integrated with these tools for the most smooth system integration. Not all of us like to automatically hand over control to our overlords under the jurisdiction that they are in, but I agree that documented options are useful. Anyhow, thanks to your email, it can soon be found by all who use DuckDuckGo and the alternative search engines! Good luck, -Rick From jm-gnutls at themarvins.org Wed Feb 24 06:36:59 2016 From: jm-gnutls at themarvins.org (John Marvin) Date: Tue, 23 Feb 2016 22:36:59 -0700 Subject: [gnutls-help] Reading non-standard bag attributes in a PKCS12 file Message-ID: <56CD417B.6010201@themarvins.org> I'm trying to read bag attributes for the bag containing the private key in a PKCS12 file. There are some specific routines for reading the local Key ID and the friendly name, but I don't see any equivalent of gnutls_x509_crt_get_dn_oid() or other routines to read other attributes (non-standard attributes in this case). Am I missing something, or am I just going to have to call gnutls_pkcs_bag_get_data() and start parsing the encoded data myself? Thanks, John From nmav at gnutls.org Thu Feb 25 09:43:42 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 25 Feb 2016 09:43:42 +0100 Subject: [gnutls-help] Reading non-standard bag attributes in a PKCS12 file In-Reply-To: <56CD417B.6010201@themarvins.org> References: <56CD417B.6010201@themarvins.org> Message-ID: On Wed, Feb 24, 2016 at 6:36 AM, John Marvin wrote: > I'm trying to read bag attributes for the bag containing the private key in > a PKCS12 file. There are some specific routines for reading the local Key ID > and the friendly name, but I don't see any equivalent of > gnutls_x509_crt_get_dn_oid() or other routines to read other attributes > (non-standard attributes in this case). There aren't any as far as I remember. > Am I missing something, or am I just going to have to call > gnutls_pkcs_bag_get_data() and start parsing the encoded data myself? Correct. If you think that can be of value to others as well, and there is something you could propose to improve this API in that aspect (or better send a patch), please do. However, my early impression of PKCS#12 was that this is a terrible format for a file, and can be extended in any unexpected way, so I kept the features limited to standard fields so that the API is kept sane and simple. regards, Nikos From dwayne.gulla1 at verizon.com Wed Feb 10 20:45:31 2016 From: dwayne.gulla1 at verizon.com (Gulla, Dwayne) Date: Wed, 10 Feb 2016 19:45:31 -0000 Subject: [gnutls-help] GnuTLS compatibility with RHEL 4 Message-ID: Hello, We have some legacy Linux servers some are running RHEL 4 and 5. We require support for TLS 1.2. We cannot upgrade the OS (it will conflict with a lot of the existing software installed). Originally we wanted to utilize OpenSSL 1.0.1 and turn off TLSv3. But we cannot install OpenSSL 1.0.1 unless the OS is bumped to 6.5. So I'd like to know if there is a version of GnuTLS that supports TLS 1.2 and is compatible with RHEL 4 and 5? I could not find anything in your documentation relevant to compatibility. Thanks in advance, Dwayne -------------- next part -------------- An HTML attachment was scrubbed... URL: From wk at gnupg.org Wed Feb 10 21:28:17 2016 From: wk at gnupg.org (Werner Koch) Date: Wed, 10 Feb 2016 20:28:17 -0000 Subject: [gnutls-help] Availability of gnutls.org over HTTPS In-Reply-To: (Nikos Mavrogiannopoulos's message of "Wed, 10 Feb 2016 09:59:14 +0100") References: <20160209150600.GB3060@orkisz> Message-ID: <87ziv8bar8.fsf@vigenere.g10code.de> On Wed, 10 Feb 2016 09:59, nmav at gnutls.org said: > The reason is that the server we are hosted did not support SSL/TLS. > However, now I see that there is https available for www.gnupg.org. For a long time actually. > Werner could TLS be enabled for gnutls as well? I am currently travelling but I can take care of this on Friday. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz. From anton.vojlenko at gmail.com Sat Feb 27 12:58:50 2016 From: anton.vojlenko at gmail.com (Anton) Date: Sat, 27 Feb 2016 13:58:50 +0200 Subject: [gnutls-help] libgnutls undefined reference Message-ID: <56D18F7A.8090600@gmail.com> Hello All, When I'm trying to build the latest GnuTLS package for CentOS 6.7 64bit I have next error: make[4]: Entering directory `/home/tokezo/gnutls-3.4.9/src' CCLD psktool ../lib/.libs/libgnutls.so: undefined reference to `nettle_secp_192r1' ../lib/.libs/libgnutls.so: undefined reference to `nettle_secp_224r1' collect2: ld returned 1 exit status make[4]: *** [psktool] Error 1 $ ldd ./lib/.libs/libgnutls.so linux-vdso.so.1 => (0x00007ffc66bb7000) libz.so.1 => /lib64/libz.so.1 (0x00007fa7f7516000) libp11-kit.so.0 => /usr/lib64/libp11-kit.so.0 (0x00007fa7f72b2000) librt.so.1 => /lib64/librt.so.1 (0x00007fa7f70a9000) libtasn1.so.6 => /usr/lib64/libtasn1.so.6 (0x00007fa7f6e97000) libnettle.so.6 => /usr/lib64/libnettle.so.6 (0x00007fa7f6c60000) libhogweed.so.4 => /usr/lib64/libhogweed.so.4 (0x00007fa7f6a34000) libgmp.so.3 => /usr/lib64/libgmp.so.3 (0x00007fa7f67d9000) libc.so.6 => /lib64/libc.so.6 (0x00007fa7f6445000) libffi.so.5 => /usr/lib64/libffi.so.5 (0x00007fa7f633d000) libdl.so.2 => /lib64/libdl.so.2 (0x00007fa7f6139000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa7f5f1c000) /lib64/ld-linux-x86-64.so.2 (0x0000003c78400000) $ objdump -T ./lib/.libs/libgnutls.so | grep 'nettle_secp_192r1\|nettle_secp_224r1' 0000000000000000 D *UND* 0000000000000000 nettle_secp_192r1 0000000000000000 D *UND* 0000000000000000 nettle_secp_224r1 # rpm -qa | grep nettle nettle-devel-3.2-2.el6.x86_64 nettle-3.2-2.el6.x86_64 # rpm -qa | grep p11-kit p11-kit-trust-0.23.2-2.el6.x86_64 p11-kit-devel-0.23.2-2.el6.x86_64 p11-kit-0.23.2-2.el6.x86_64 Any idea why it happens and how to solve it? Best regards, Anton Voylenko -------------- next part -------------- An HTML attachment was scrubbed... URL: From nmav at gnutls.org Mon Feb 29 17:09:55 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 29 Feb 2016 17:09:55 +0100 Subject: [gnutls-help] change in posting policy Message-ID: <1456762195.1861.3.camel@gnutls.org> Hello, Due to a large amount of spam received by the list, it is no longer practical to go through the list of held postings and approve them. As such, I've switched the posting policy to members only. regards, Nikos From nmav at gnutls.org Mon Feb 29 17:11:20 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 29 Feb 2016 17:11:20 +0100 Subject: [gnutls-help] libgnutls undefined reference In-Reply-To: <56D18F7A.8090600@gmail.com> References: <56D18F7A.8090600@gmail.com> Message-ID: <1456762280.1861.5.camel@gnutls.org> On Sat, 2016-02-27 at 13:58 +0200, Anton wrote: > Hello All, > > When I'm trying to build the latest GnuTLS package for CentOS 6.7 > 64bit I have next error: > > make[4]: Entering directory `/home/tokezo/gnutls-3.4.9/src' > CCLD psktool > ../lib/.libs/libgnutls.so: undefined reference to `nettle_secp_192r1' > ../lib/.libs/libgnutls.so: undefined reference to `nettle_secp_224r1' > collect2: ld returned 1 exit status > make[4]: *** [psktool] Error 1 nettle in RHEL/Centos does not include the secp192 and 224 curves. Try specifying --disable-non-suiteb-curves to gnutls. regards, Nikos From anton.vojlenko at gmail.com Mon Feb 29 17:28:21 2016 From: anton.vojlenko at gmail.com (Anton) Date: Mon, 29 Feb 2016 18:28:21 +0200 Subject: [gnutls-help] libgnutls undefined reference In-Reply-To: <1456762280.1861.5.camel@gnutls.org> References: <56D18F7A.8090600@gmail.com> <1456762280.1861.5.camel@gnutls.org> Message-ID: <56D471A5.500@gmail.com> Hi, I have already built nettle with secp192 and secp224 curves support. It was wrong decision and I should consider secp192 and secp224 curves as insecure? Thanks. Best regards, Anton On 02/29/2016 06:11 PM, Nikos Mavrogiannopoulos wrote: > On Sat, 2016-02-27 at 13:58 +0200, Anton wrote: >> Hello All, >> >> When I'm trying to build the latest GnuTLS package for CentOS 6.7 >> 64bit I have next error: >> >> make[4]: Entering directory `/home/tokezo/gnutls-3.4.9/src' >> CCLD psktool >> ../lib/.libs/libgnutls.so: undefined reference to `nettle_secp_192r1' >> ../lib/.libs/libgnutls.so: undefined reference to `nettle_secp_224r1' >> collect2: ld returned 1 exit status >> make[4]: *** [psktool] Error 1 > nettle in RHEL/Centos does not include the secp192 and 224 curves. Try > specifying --disable-non-suiteb-curves to gnutls. > > regards, > Nikos > > From nmav at gnutls.org Mon Feb 29 21:29:19 2016 From: nmav at gnutls.org (Nikos Mavrogiannopoulos) Date: Mon, 29 Feb 2016 21:29:19 +0100 Subject: [gnutls-help] libgnutls undefined reference In-Reply-To: <56D471A5.500@gmail.com> References: <56D18F7A.8090600@gmail.com> <1456762280.1861.5.camel@gnutls.org> <56D471A5.500@gmail.com> Message-ID: <1456777759.24128.4.camel@gnutls.org> On Mon, 2016-02-29 at 18:28 +0200, Anton wrote: > Hi, > > I have already built nettle with secp192 and secp224 curves support. > It was wrong decision and I should consider secp192 and secp224 > curves as insecure? I do not believe that the Fedora/RHEL decision not to include secp192 and secp224 was related to security. Given today's situation though supporting the 192 and 224 curves doesn't provide much of an advantage. regards, Nikos