From simon at josefsson.org  Thu Jun  7 16:00:47 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Thu, 07 Jun 2007 16:00:47 +0200
Subject: [Help-gnutls] FYI: Building under uClinux
Message-ID: <874pljampc.fsf@mocca.josefsson.org>

In case anyone is interested in building libgpg-error, libgcrypt, gnutls
and/or gsasl under uClinux, here are some brief instructions:

http://josefsson.org/uclinux/
http://permalink.gmane.org/gmane.linux.uclinux.devel/11539

/Simon




From mwd at cert.org  Mon Jun 11 20:17:57 2007
From: mwd at cert.org (Michael Welsh Duggan)
Date: Mon, 11 Jun 2007 14:17:57 -0400
Subject: [Help-gnutls] _gnutls_fbase64_decode and PEM headers
Message-ID: <tnt1wgi9wyy.fsf@maru.green.cert.org>

Why does _gnutls_fbase64_decode not appear to account for encapsulated
header fields before the base-64 encoded data, as exemplified by
section 4.6 of rfc1421?  I ran into this error using gnutls 1.4.1,
using the gnutls_certificate_set_x509_key_file function with a key
file that includes encapsulated headers.

        rv = gnutls_certificate_set_x509_key_file(queue->root->cred,
                                                  cert_filename,
                                                  key_filename,
                                                  GNUTLS_X509_FMT_PEM);

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,ED00000000000000

BASE64ENCODEDSTUFF...
-----END RSA PRIVATE KEY-----

This ends up returning GNUTLS_E_BASE64_DECODING_ERROR, due to the fact
that it assumes Proc-Type:, etc., are part of the base-64 encoding.

Question B: Am I doing something wrong?

-- 
Michael Welsh Duggan
(mwd at cert.org)










From simon at josefsson.org  Mon Jun 11 22:08:46 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Mon, 11 Jun 2007 22:08:46 +0200
Subject: [Help-gnutls] Re: _gnutls_fbase64_decode and PEM headers
In-Reply-To: <tnt1wgi9wyy.fsf@maru.green.cert.org> (Michael Welsh Duggan's
	message of "Mon, 11 Jun 2007 14:17:57 -0400")
References: <tnt1wgi9wyy.fsf@maru.green.cert.org>
Message-ID: <87lkeqntip.fsf@mocca.josefsson.org>

Michael Welsh Duggan <mwd at cert.org> writes:

> Why does _gnutls_fbase64_decode not appear to account for encapsulated
> header fields before the base-64 encoded data, as exemplified by
> section 4.6 of rfc1421?  I ran into this error using gnutls 1.4.1,
> using the gnutls_certificate_set_x509_key_file function with a key
> file that includes encapsulated headers.
>
>         rv = gnutls_certificate_set_x509_key_file(queue->root->cred,
>                                                   cert_filename,
>                                                   key_filename,
>                                                   GNUTLS_X509_FMT_PEM);
>
> -----BEGIN RSA PRIVATE KEY-----
> Proc-Type: 4,ENCRYPTED
> DEK-Info: DES-EDE3-CBC,ED00000000000000
>
> BASE64ENCODEDSTUFF...
> -----END RSA PRIVATE KEY-----
>
> This ends up returning GNUTLS_E_BASE64_DECODING_ERROR, due to the fact
> that it assumes Proc-Type:, etc., are part of the base-64 encoding.

That formats is not supported by GnuTLS.  As far as I know, the format
is not standardized, and is specific to OpenSSL.  Without more
information or security analysis, I would be sceptic about its security
properties.

If you or someone wants to work on supporting this, we could add it to
libgnutls-extra (let's not add more non-essential stuff to the core
libgnutls).

> Question B: Am I doing something wrong?

Yes, most likely you really want to use PKCS#12 to transport encrypted
private keys instead.  That format can also encode client certificates
and/or CA certificates as well.  The API to use is:

  extern int
    gnutls_certificate_set_x509_simple_pkcs12_file
    (gnutls_certificate_credentials_t res, const char *pkcs12file,
     gnutls_x509_crt_fmt_t type, const char *password);

You should be able to convert to from OpenSSL-encrypted files to PKCS#11
using one of the OpenSSL command line tools.

/Simon




From kovacsp3 at comcast.net  Tue Jun 12 17:26:53 2007
From: kovacsp3 at comcast.net (Philip Kovacs)
Date: Tue, 12 Jun 2007 11:26:53 -0400
Subject: [Help-gnutls] Handling "normal" peer errors on invalid certs
Message-ID: <20070612152653.GA17611@porthos.lan.net>

Hi.  I'm new to GnuTLS.  I'm using it for a client-server library and 
I have a fairly basic question.

When my server is configured to require x.509 client certificates,
and the client either fails to send one, or sends an invalid one,
the server detects this error during its gnuttls_handshake() and
I have the server break off the connection, as desired.

The client's gnutls_handshake(), upon server break-off is returning
either GNUTLS_E_PUSH_ERROR or GNUTLS_E_UNEXPECTED_PACKET_LENGTH.

The server situation is similar:  if the client detects an invalid
server certificate, I have the client break off the connection.  
The server then sees GNUTLS_E_UNEXPECTED_PACKET_LENGTH in its (first) 
gnutls_record_recv().

Is there something more I need to do in order to close the communication
down more "gracefully" in situations where certificate failures are seen?

Just seems odd to be handling GNUTLS_E_PUSH_ERROR or
GNUTLS_E_UNEXPECTED_PACKET_LENGTH "normally" when the other side doesn't
like the certificate.

I'm using GnuTLS 1.4.4 for the moment.

Thanks.

Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: </pipermail/attachments/20070612/8f831a2b/attachment.pgp>

From simon at josefsson.org  Tue Jun 12 18:27:31 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Tue, 12 Jun 2007 18:27:31 +0200
Subject: [Help-gnutls] Re: Handling "normal" peer errors on invalid certs
In-Reply-To: <20070612152653.GA17611@porthos.lan.net> (Philip Kovacs's message
	of "Tue, 12 Jun 2007 11:26:53 -0400")
References: <20070612152653.GA17611@porthos.lan.net>
Message-ID: <87myz5t9xo.fsf@mocca.josefsson.org>

Philip Kovacs <kovacsp3 at comcast.net> writes:

> Hi.  I'm new to GnuTLS.  I'm using it for a client-server library and 
> I have a fairly basic question.

Hi!  Welcome.

> When my server is configured to require x.509 client certificates,
> and the client either fails to send one, or sends an invalid one,
> the server detects this error during its gnuttls_handshake() and
> I have the server break off the connection, as desired.
>
> The client's gnutls_handshake(), upon server break-off is returning
> either GNUTLS_E_PUSH_ERROR or GNUTLS_E_UNEXPECTED_PACKET_LENGTH.
>
> The server situation is similar:  if the client detects an invalid
> server certificate, I have the client break off the connection.  
> The server then sees GNUTLS_E_UNEXPECTED_PACKET_LENGTH in its (first) 
> gnutls_record_recv().
>
> Is there something more I need to do in order to close the communication
> down more "gracefully" in situations where certificate failures are seen?
>
> Just seems odd to be handling GNUTLS_E_PUSH_ERROR or
> GNUTLS_E_UNEXPECTED_PACKET_LENGTH "normally" when the other side doesn't
> like the certificate.

I suspect the error handling here is simply sub-optimal, and that you
aren't doing anything wrong.

Creating a self-test inside GnuTLS tests/ that trigger this situation
would help.  Having that self-test would help us test what kind of
errors really should be returned in this situation, and how to return
them.  I can't commit to work on this now, so I added the following to
doc/TODO:

- Investigate why failed client authentication results in weird error
  messages.  See http://permalink.gmane.org/gmane.network.gnutls.general/875

If you or others wants to work on it, you are very welcome to do so.

/Simon




From kovacsp3 at comcast.net  Tue Jun 12 22:20:44 2007
From: kovacsp3 at comcast.net (Philip Kovacs)
Date: Tue, 12 Jun 2007 16:20:44 -0400
Subject: [Help-gnutls] Re: Handling "normal" peer errors on invalid certs
Message-ID: <20070612202044.GA15117@porthos.lan.net>

> Simon Josefsson <simon at josefsson.org> wrote:

>I suspect the error handling here is simply sub-optimal, and that you
>aren't doing anything wrong.

>Creating a self-test inside GnuTLS tests/ that trigger this situation
>would help.  Having that self-test would help us test what kind of
>errors really should be returned in this situation, and how to return
>them.  I can't commit to work on this now, so I added the following to
>doc/TODO:

>- Investigate why failed client authentication results in weird error
>  messages.  See http://permalink.gmane.org/gmane.network.gnutls.general/875

>If you or others wants to work on it, you are very welcome to do so.

>/Simon

Hi.  I did some investigating and can report a little more detail.

I began with replacing the underlying push function, send(), with
a variant, send_msg_nosignal(), in order to avoid the nagging
SIGPIPE that is being thrown when send() is called against a broken
connection.  Unless you catch SIGPIPE (or ignore it), the app. just
exits with -141 (Unknown error) when gnutls pushes against a broken
connection.

#ifdef HAVE_MSG_NOSIGNAL
static ssize_t
_send_msg_nosignal (gnutls_transport_ptr_t  ptr,
                    const void             *buf,
                    size_t                  buflen)
{
  ssize_t ret = send ( (int)ptr, buf, buflen, MSG_NOSIGNAL);

  /* Here I can look at the actual error.  On Linux I am seeing
     EPIPE.  Other unices probably return ENOTCONN.   */
  ...

  return ret;
}
#endif

and elsewhere in my code I issue this statement as I am setting up
the tls session:

#ifdef HAVE_MSG_NOSIGNAL
  gnutls_transport_set_push_function (tls->session, _send_msg_nosignal);
#endif

The error that is causing gnutls to issue GNUTLS_E_PUSH_ERROR in my
variant above is that send() is returning EPIPE.   I tried replacing
the EPIPE with ENOTCONN, just to see if gnutls "behaved better" on this
error.  I still get GNUTLS_E_PUSH_ERROR.

That seems to explain the reason for the GNUTLS_E_PUSH_ERROR client-side
errors when the server breaks off, and vice versa.  Perhaps the other
error I see, GNUTLS_E_UNEXPECTED_PACKET_LENGTH, when a peer breaks off
may be due to some unread TLS bytes in the tcp buffers?

I suppose, for now, the way to proceed is simply to treat

GNUTLS_E_PUSH_ERROR
GNUTLS_E_UNEXPECTED_PACKET_LENGTH

as "acceptable" errors that may occur during the handshake, indicating
that the peer broke off because it doesn't like our certificate, or that
we failed to send one when required to do so.

Phil

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: </pipermail/attachments/20070612/3b267bb0/attachment.pgp>

From mwd at cert.org  Thu Jun 14 17:51:47 2007
From: mwd at cert.org (Michael Welsh Duggan)
Date: Thu, 14 Jun 2007 11:51:47 -0400
Subject: [Help-gnutls] Re: _gnutls_fbase64_decode and PEM headers
In-Reply-To: <87lkeqntip.fsf@mocca.josefsson.org> (Simon Josefsson's message
	of "Mon\, 11 Jun 2007 22\:08\:46 +0200")
References: <tnt1wgi9wyy.fsf@maru.green.cert.org>
	<87lkeqntip.fsf@mocca.josefsson.org>
Message-ID: <tntir9qjzzg.fsf@maru.green.cert.org>

Simon Josefsson <simon at josefsson.org> writes:

>> Question B: Am I doing something wrong?
>
> Yes, most likely you really want to use PKCS#12 to transport encrypted
> private keys instead.  That format can also encode client certificates
> and/or CA certificates as well.  The API to use is:
>
>   extern int
>     gnutls_certificate_set_x509_simple_pkcs12_file
>     (gnutls_certificate_credentials_t res, const char *pkcs12file,
>      gnutls_x509_crt_fmt_t type, const char *password);
>
> You should be able to convert to from OpenSSL-encrypted files to PKCS#11
> using one of the OpenSSL command line tools.

Okay.  I have attempted this using the gnutls certtool program.  To be
specific:

a) I created a cert and key using certtool.
b) I used 
        rv = gnutls_certificate_set_x509_key_file(queue->root->cred,
                                                  cert_filename,
                                                  key_filename,
                                                  GNUTLS_X509_FMT_PEM);

This worked.  I then tried the following:

a) Created a PKCS-12 key using:
   certtool --load-certificate clientcert.pem \
     --load-privkey clientkey.pem --to-p12 --outfile client.p12
   (Used an empty password)
b) Used 
        rv = gnutls_certificate_set_x509_simple_pkcs12_file(
            queue->root->cred,
            cert_filename,
            GNUTLS_X509_FMT_PEM,
            password);
   (Used an empty password)

When I do this, I get the following error:
    ASN1 parser: Error in TAG.

Gnutls version is 1.4.1.  Any suggestions?

-- 
Michael Welsh Duggan
(mwd at cert.org)




From mwd at cert.org  Thu Jun 14 18:18:21 2007
From: mwd at cert.org (Michael Welsh Duggan)
Date: Thu, 14 Jun 2007 12:18:21 -0400
Subject: [Help-gnutls] Re: _gnutls_fbase64_decode and PEM headers
In-Reply-To: <tntir9qjzzg.fsf@maru.green.cert.org> (Michael Welsh Duggan's
	message of "Thu\, 14 Jun 2007 11\:51\:47 -0400")
References: <tnt1wgi9wyy.fsf@maru.green.cert.org>
	<87lkeqntip.fsf@mocca.josefsson.org>
	<tntir9qjzzg.fsf@maru.green.cert.org>
Message-ID: <tntejkejyr6.fsf@maru.green.cert.org>

Michael Welsh Duggan <mwd at cert.org> writes:

> This worked.  I then tried the following:
>
> a) Created a PKCS-12 key using:
>    certtool --load-certificate clientcert.pem \
>      --load-privkey clientkey.pem --to-p12 --outfile client.p12
>    (Used an empty password)
> b) Used 
>         rv = gnutls_certificate_set_x509_simple_pkcs12_file(
>             queue->root->cred,
>             cert_filename,
>             GNUTLS_X509_FMT_PEM,
>             password);
>    (Used an empty password)
>
> When I do this, I get the following error:
>     ASN1 parser: Error in TAG.
>
> Gnutls version is 1.4.1.  Any suggestions?

Oh, and just a few more pieces of debug information.  It fails in the
first asn1_der_decoding in _pkcs12_decode_safe_contents called from
gnutls_pkcs12_bag_decrypt.

#0  _pkcs12_decode_safe_contents (content=0xbfd66898, bag=0x83cd120) at pkcs12.c:371
#1  0x009704bd in gnutls_pkcs12_bag_decrypt (bag=0x83cd120, pass=0x0) at pkcs12_bag.c:662
#2  0x0093d55f in parse_pkcs12 (res=0x83ca480, p12=0x83c0700, password=0x0, key=0xbfd6695c, cert=0xbfd66958, crl=0xbfd66954) at gnutls_x509.c:1850
#3  0x0093dc3a in gnutls_certificate_set_x509_simple_pkcs12_file (res=0x83ca480, pkcs12file=0xbfd68830 "/afs/cert.org/usr/mwd/projects/test/client.p12", type=GNUTLS_X509_FMT_PEM, password=0x0) at gnutls_x509.c:2043
#4  0x0804f25e in skMsgQueueAddPKCS12 (queue=0x83ad850, cert_filename=0xbfd68830 "/afs/cert.org/usr/mwd/projects/test/client.p12", password=0x0) at skmsg.c:1009
#5  0x0804de49 in startTransferDaemon () at rwtransfer.c:1315
#6  0x0804b97c in main (argc=Cannot access memory at address 0x1

-- 
Michael Welsh Duggan
(mwd at cert.org)




From mwd at cert.org  Mon Jun 18 17:18:01 2007
From: mwd at cert.org (Michael Welsh Duggan)
Date: Mon, 18 Jun 2007 11:18:01 -0400
Subject: [Help-gnutls] Re: _gnutls_fbase64_decode and PEM headers
In-Reply-To: <tntejkejyr6.fsf@maru.green.cert.org> (Michael Welsh Duggan's
	message of "Thu\, 14 Jun 2007 12\:18\:21 -0400")
References: <tnt1wgi9wyy.fsf@maru.green.cert.org>
	<87lkeqntip.fsf@mocca.josefsson.org>
	<tntir9qjzzg.fsf@maru.green.cert.org>
	<tntejkejyr6.fsf@maru.green.cert.org>
Message-ID: <tntsl8p47h2.fsf@maru.green.cert.org>

Pinging once more.  Any ideas?

Michael Welsh Duggan <mwd at cert.org> writes:

> Michael Welsh Duggan <mwd at cert.org> writes:
>
>> This worked.  I then tried the following:
>>
>> a) Created a PKCS-12 key using:
>>    certtool --load-certificate clientcert.pem \
>>      --load-privkey clientkey.pem --to-p12 --outfile client.p12
>>    (Used an empty password)
>> b) Used 
>>         rv = gnutls_certificate_set_x509_simple_pkcs12_file(
>>             queue->root->cred,
>>             cert_filename,
>>             GNUTLS_X509_FMT_PEM,
>>             password);
>>    (Used an empty password)
>>
>> When I do this, I get the following error:
>>     ASN1 parser: Error in TAG.
>>
>> Gnutls version is 1.4.1.  Any suggestions?
>
> Oh, and just a few more pieces of debug information.  It fails in the
> first asn1_der_decoding in _pkcs12_decode_safe_contents called from
> gnutls_pkcs12_bag_decrypt.
>
> #0  _pkcs12_decode_safe_contents (content=0xbfd66898, bag=0x83cd120) at pkcs12.c:371
> #1  0x009704bd in gnutls_pkcs12_bag_decrypt (bag=0x83cd120, pass=0x0) at pkcs12_bag.c:662
> #2  0x0093d55f in parse_pkcs12 (res=0x83ca480, p12=0x83c0700, password=0x0, key=0xbfd6695c, cert=0xbfd66958, crl=0xbfd66954) at gnutls_x509.c:1850
> #3  0x0093dc3a in gnutls_certificate_set_x509_simple_pkcs12_file (res=0x83ca480, pkcs12file=0xbfd68830 "/afs/cert.org/usr/mwd/projects/test/client.p12", type=GNUTLS_X509_FMT_PEM, password=0x0) at gnutls_x509.c:2043
> #4  0x0804f25e in skMsgQueueAddPKCS12 (queue=0x83ad850, cert_filename=0xbfd68830 "/afs/cert.org/usr/mwd/projects/test/client.p12", password=0x0) at skmsg.c:1009
> #5  0x0804de49 in startTransferDaemon () at rwtransfer.c:1315
> #6  0x0804b97c in main (argc=Cannot access memory at address 0x1

-- 
Michael Welsh Duggan
(mwd at cert.org)




From home at alexhudson.com  Wed Jun 20 14:04:08 2007
From: home at alexhudson.com (Alex Hudson)
Date: Wed, 20 Jun 2007 13:04:08 +0100
Subject: [Help-gnutls] Creating self-signed certicates using the GnuTLS APi
Message-ID: <1182341048.3140.3.camel@laptop.alexhudson.com>


Hey.

I'm having trouble creating a self-signed certificate.

I've created the private key fine, and then attempt to do something
like:

	gnutls_x509_crt_init(&certificate);
	gnutls_x509_crt_set_activation_time(certificate, time(NULL));
	gnutls_x509_crt_set_expiration_time(certificate, time(NULL) + (700 * 24
* 60 * 60));
	gnutls_x509_crt_set_key(certificate, key);
	gnutls_x509_crt_set_version(certificate, 1);
	gnutls_x509_crt_set_serial(certificate, &cert_version, sizeof(int));

... but with more error-checking. I then use
gnutls_x509_crt_set_dn_by_oid() to set some more data on the
certificate, and gnutls_x509_crt_set_key_usage(), but when I come to use
gnutls_x509_crt_export() I get:

	ASN1 parser: Value was not found.

It seems I'm doing something pretty basically wrong. I've tried
following what certtool does, but to be honest I got lost :D 

Am I doing something clearly wrong? Are there any plain examples I could
look at?

Many thanks,

Alex.





From simon at josefsson.org  Wed Jun 20 14:09:03 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Wed, 20 Jun 2007 14:09:03 +0200
Subject: [Help-gnutls] Re: Creating self-signed certicates using the GnuTLS
	APi
In-Reply-To: <1182341048.3140.3.camel@laptop.alexhudson.com> (Alex Hudson's
	message of "Wed, 20 Jun 2007 13:04:08 +0100")
References: <1182341048.3140.3.camel@laptop.alexhudson.com>
Message-ID: <87y7ierfog.fsf@mocca.josefsson.org>

Alex Hudson <home at alexhudson.com> writes:

> Hey.
>
> I'm having trouble creating a self-signed certificate.
>
> I've created the private key fine, and then attempt to do something
> like:
>
> 	gnutls_x509_crt_init(&certificate);
> 	gnutls_x509_crt_set_activation_time(certificate, time(NULL));
> 	gnutls_x509_crt_set_expiration_time(certificate, time(NULL) + (700 * 24
> * 60 * 60));
> 	gnutls_x509_crt_set_key(certificate, key);
> 	gnutls_x509_crt_set_version(certificate, 1);
> 	gnutls_x509_crt_set_serial(certificate, &cert_version, sizeof(int));
>
> ... but with more error-checking. I then use
> gnutls_x509_crt_set_dn_by_oid() to set some more data on the
> certificate, and gnutls_x509_crt_set_key_usage(), but when I come to use
> gnutls_x509_crt_export() I get:
>
> 	ASN1 parser: Value was not found.

That error is typically returned when some non-optional fields in the
certificate have not yet been set.

> It seems I'm doing something pretty basically wrong. I've tried
> following what certtool does, but to be honest I got lost :D 
>
> Am I doing something clearly wrong? Are there any plain examples I could
> look at?

Did you sign the certificate using gnutls_x509_crt_sign2 or similar?
The signature field is not optional in a certificate.

Generally, I think certtool.c is the best example available, even though
it is a rather large program.  But, if my hint helps, please consider to
submit a stripped-down example program to create a self-signed
certificate so that others may learn from it.

/Simon




From mail.kumar at gmail.com  Fri Jun 29 07:57:31 2007
From: mail.kumar at gmail.com (Amit kumar)
Date: Fri, 29 Jun 2007 11:27:31 +0530
Subject: [Help-gnutls] gnutls query-- want to suppress comnpilation of
	libgnutls-extra.so
Message-ID: <566da6e0706282257n4348dae4gaa3851784ea3bce9@mail.gmail.com>

Hi All,

Our application is providing support for TLS using gnutls library version
1.4.1.

As we are only using functions defined in library libgnutls.so do we need
libgnutls-extra.so.

We are not using openPGP and openSSL feature provided by
libgnutls-extra.soand thus want to suppress the compilation of
gnutls-extra library when
compiling gnutls source. Is there any way to do it.


I have verified using ldd command that libgnutls-extra.so requires
libgnutls.so for linking and not vice versa thus libgnutls.so library can be
used independently.

I just need some information on how to avoid compilation of libgnutls-extra.

An early help would be appreciated.

Thanks & Regards
Amit Kumar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20070629/6a88f583/attachment.htm>

From simon at josefsson.org  Fri Jun 29 14:07:17 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 29 Jun 2007 14:07:17 +0200
Subject: [Help-gnutls] Re: gnutls query-- want to suppress comnpilation of
	libgnutls-extra.so
In-Reply-To: <566da6e0706282257n4348dae4gaa3851784ea3bce9@mail.gmail.com>
	(Amit kumar's message of "Fri, 29 Jun 2007 11:27:31 +0530")
References: <566da6e0706282257n4348dae4gaa3851784ea3bce9@mail.gmail.com>
Message-ID: <87tzsrhslm.fsf@mocca.josefsson.org>

"Amit kumar" <mail.kumar at gmail.com> writes:

> Hi All,
>
> Our application is providing support for TLS using gnutls library version
> 1.4.1.

Hi and welcome!

> As we are only using functions defined in library libgnutls.so do we need
> libgnutls-extra.so.

No.

> We are not using openPGP and openSSL feature provided by
> libgnutls-extra.soand thus want to suppress the compilation of
> gnutls-extra library when
> compiling gnutls source. Is there any way to do it.

Just don't link your application against libgnutls-extra and you should
be fine.

> I have verified using ldd command that libgnutls-extra.so requires
> libgnutls.so for linking and not vice versa thus libgnutls.so library can be
> used independently.

Correct.

> I just need some information on how to avoid compilation of libgnutls-extra.
>
> An early help would be appreciated.

If you really need to avoid _compiling_ libgnutls-extra (although I
don't see why?), you could run './configure' and then invoke 'make
install' manually in lgl/, gl/, includes/, and lib/.

However, I recommend that you simply do 'make install' and then decide
when linking your application whether to use libgnutls-extra or not.

/Simon




From mail.kumar at gmail.com  Fri Jun 29 16:34:58 2007
From: mail.kumar at gmail.com (Amit kumar)
Date: Fri, 29 Jun 2007 20:04:58 +0530
Subject: [Help-gnutls] Re: gnutls query-- want to suppress comnpilation of
	libgnutls-extra.so
In-Reply-To: <87tzsrhslm.fsf@mocca.josefsson.org>
References: <566da6e0706282257n4348dae4gaa3851784ea3bce9@mail.gmail.com>
	<87tzsrhslm.fsf@mocca.josefsson.org>
Message-ID: <566da6e0706290734u28d6aacflfaf75bf026436b7d@mail.gmail.com>

Hello Simon,

Thanks for the reply.

I do have one more query.

Does gnutls provides Transport Layer Security using SSL?

If the answer to the above question is YES than how will this be provided in
our application as we are not linking or using any API's defined in SSL
library.

If the answer to the above question is NO than how does libgnutls provides
security to the transport connection without using SSL?

Thanks
Amit

On 6/29/07, Simon Josefsson <simon at josefsson.org> wrote:
>
> "Amit kumar" <mail.kumar at gmail.com> writes:
>
> > Hi All,
> >
> > Our application is providing support for TLS using gnutls library
> version
> > 1.4.1.
>
> Hi and welcome!
>
> > As we are only using functions defined in library libgnutls.so do we
> need
> > libgnutls-extra.so.
>
> No.
>
> > We are not using openPGP and openSSL feature provided by
> > libgnutls-extra.soand thus want to suppress the compilation of
> > gnutls-extra library when
> > compiling gnutls source. Is there any way to do it.
>
> Just don't link your application against libgnutls-extra and you should
> be fine.
>
> > I have verified using ldd command that libgnutls-extra.so requires
> > libgnutls.so for linking and not vice versa thus libgnutls.so library
> can be
> > used independently.
>
> Correct.
>
> > I just need some information on how to avoid compilation of
> libgnutls-extra.
> >
> > An early help would be appreciated.
>
> If you really need to avoid _compiling_ libgnutls-extra (although I
> don't see why?), you could run './configure' and then invoke 'make
> install' manually in lgl/, gl/, includes/, and lib/.
>
> However, I recommend that you simply do 'make install' and then decide
> when linking your application whether to use libgnutls-extra or not.
>
> /Simon
>



-- 
Amit Kumar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20070629/d07347f8/attachment.htm>

From simon at josefsson.org  Fri Jun 29 17:12:31 2007
From: simon at josefsson.org (Simon Josefsson)
Date: Fri, 29 Jun 2007 17:12:31 +0200
Subject: [Help-gnutls] Re: gnutls query-- want to suppress comnpilation of
	libgnutls-extra.so
In-Reply-To: <566da6e0706290734u28d6aacflfaf75bf026436b7d@mail.gmail.com>
	(Amit kumar's message of "Fri, 29 Jun 2007 20:04:58 +0530")
References: <566da6e0706282257n4348dae4gaa3851784ea3bce9@mail.gmail.com>
	<87tzsrhslm.fsf@mocca.josefsson.org>
	<566da6e0706290734u28d6aacflfaf75bf026436b7d@mail.gmail.com>
Message-ID: <87zm2ig5gg.fsf@mocca.josefsson.org>

"Amit kumar" <mail.kumar at gmail.com> writes:

> Hello Simon,
>
> Thanks for the reply.
>
> I do have one more query.
>
> Does gnutls provides Transport Layer Security using SSL?

Yes, the point of the GnuTLS library is to implement and provide SSLv3
and TLSv1+.  I'm not sure if I understand your question though.

> If the answer to the above question is YES than how will this be provided in
> our application as we are not linking or using any API's defined in SSL
> library.

You'll need to modify your application to use GnuTLS.  If you don't want
to do that, consider using NuFW, IPSEC or similar.

/Simon