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