From jas at extundo.com  Thu Oct  7 01:54:45 2004
From: jas at extundo.com (Simon Josefsson)
Date: Thu, 07 Oct 2004 01:54:45 +0200
Subject: [gnutls-dev] gnutls 1.0.21
Message-ID: <ilullej767u.fsf@latte.josefsson.org>

Hello.  This release should fix a few problems.

There is at least one known problem, in that libgnutls uses
(v)snprintf, which is not portable.  On the 1.1.x branch, I intend to
solve that (and similar issues) by using the gnulib portability files.
For 1.0.x, I'll accept a patch that rewrites the calls to snprintf to
do something else (looks feasible, only around 10 uncomplicated
calls), if someone strongly need this and is willing to do the work.
I do recommend moving to 1.1.x instead, though.  Thanks to Yoann for
reporting this.

If I have forgotten something, please holler.

Btw, I have created a little tool to generate "recent CVS activity"
web pages, the page for gnutls CVS is available from:

http://josefsson.org/gnutls/cvsactivity.html

I notice now that the page doesn't handle branches well.  That is, it
mixes entries for 1.0.x and 1.1.x, which make things difficult to
read.  And the tag entry seem to have a bad timestamp.  O well.

Happy hacking,
Simon

Version 1.0.21 (07/10/2004)
- Fix memory leak in gnutls_certificate_verify_peers and
  gnutls_certificate_free_credentials, report and patch by Simon
  Posnjak <simon.posnjak at cetrtapot.si>.
- Fix crash in `certtool --to-p12 --load-privkey foo', i.e. exporting
  a key and no certificate to PKCS#12.
- Fix objdir != srcdir builds, reported by "Gerrit P. Haase"
  <gp at familiehaase.de>.
- Avoid redefining getpass if system already has it, reported by
  Yoann Vandoorselaere <yoann at prelude-ids.org>.
- Add new example "ex-rfc2818" for certificate verification, from Nikos.
- Known bug: the library require snprintf.




From jas at extundo.com  Thu Oct  7 02:10:59 2004
From: jas at extundo.com (Simon Josefsson)
Date: Thu, 07 Oct 2004 02:10:59 +0200
Subject: [gnutls-dev] gnutls 1.1.19
Message-ID: <iluekkb75gs.fsf@latte.josefsson.org>

Adding to my last message, I don't believe I have mentioned on this
list that there are daily snapshots available from:

http://josefsson.org/daily/gnutls/

They are set up just like the real releases, i.e., you build them
using ./configure && make.

* Version 1.1.19 (2004-10-07)
- Fix memory leak in gnutls_certificate_verify_peers and
  gnutls_certificate_free_credentials, report and patch by Simon
  Posnjak <simon.posnjak at cetrtapot.si>.
- Fix crash in `certtool --to-p12 --load-privkey foo', i.e. exporting
  a key and no certificate to PKCS#12.
- Fix objdir != srcdir builds, reported by "Gerrit P. Haase"
  <gp at familiehaase.de>.
- Fixes faulty getpass implementation in libextra/opencdk/, reported
  by Yoann Vandoorselaere <yoann at prelude-ids.org>.
- Uses memmem instead of strnstr in lib/.
- Using more GNULib portability files, although not yet inside lib/.
- Added gnutls_certificate_verify_peers to gnutls/compat.h.
  Nikos deprecated gnutls_certificate_verify_peers in favor of
  gnutls_certificate_verify_peers2 earlier in the 1.1 branch.
- Improvements to the manual.
- Add new example "ex-rfc2818" for certificate verification, from Nikos.
- Known bug: the library require snprintf.  This has not yet been
  fixed, but will be handled via GNULib later on.




From joe at manyfish.co.uk  Thu Oct  7 23:04:55 2004
From: joe at manyfish.co.uk (Joe Orton)
Date: Thu, 7 Oct 2004 22:04:55 +0100
Subject: [gnutls-dev] non-ASCII ASN.1 string types
Message-ID: <20041007210455.GA29360@manyfish.co.uk>

The gnutls_x509_crq_get_dn_by_oid documentation states the output will
be "ASCII or UTF-8 encoded, depending on certificate data".  Is there
really code to back that up?

For a certificate with the OU encoded as a BMPString, the function
appears to simply give back the raw UCS-2 data, likewise a T61String OU
is given back as-is.

Aleix and I are working on adding GNU TLS support to the neon HTTP
library, and the test suite is finding some issues like this.

joe



From joe at manyfish.co.uk  Thu Oct  7 23:21:20 2004
From: joe at manyfish.co.uk (Joe Orton)
Date: Thu, 7 Oct 2004 22:21:20 +0100
Subject: [gnutls-dev] UTCTime to time_t drops seconds
Message-ID: <20041007212120.GC16454@manyfish.co.uk>

I don't have a simple repro case for this, but it looks like a fairly
simple bug: the UTCTime -> time_t conversion is dropping the seconds
digits, as returned by the gnutls_x509_crt_get_*_time functions.

I'm working from RPMs so I don't have a patch to test, but it looks
simply like _gnutls_x509_time2gtime should check whether the time string
includes the seconds digits (which are optional in UTCTime), instead of
setting tm_sec to 0 always, something like:

   if (strlen(ttime) >= 2) {
       memcpy(xx, ttime, 2);
       etime.tm_sec = atoi(xx);
       ttime += 2;
   } else {
       etime.tm_sec = 0;
   }

joe



From nmav at gnutls.org  Fri Oct  8 10:22:47 2004
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 8 Oct 2004 10:22:47 +0200
Subject: [gnutls-dev] non-ASCII ASN.1 string types
In-Reply-To: <20041007210455.GA29360@manyfish.co.uk>
References: <20041007210455.GA29360@manyfish.co.uk>
Message-ID: <200410081022.47498.nmav@gnutls.org>

On Thursday 07 October 2004 23:04, Joe Orton wrote:
> The gnutls_x509_crq_get_dn_by_oid documentation states the output will
> be "ASCII or UTF-8 encoded, depending on certificate data".  Is there
> really code to back that up?
>
> For a certificate with the OU encoded as a BMPString, the function
> appears to simply give back the raw UCS-2 data, likewise a T61String OU
> is given back as-is.
Types other than UTF8String and ascii are not supported yet.
It should have returned an error though (I'll check it).


> joe

-- 
Nikos Mavrogiannopoulos



From nmav at gnutls.org  Tue Oct 12 22:07:53 2004
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 12 Oct 2004 22:07:53 +0200
Subject: [gnutls-dev] non-ASCII ASN.1 string types
In-Reply-To: <20041007210455.GA29360@manyfish.co.uk>
References: <20041007210455.GA29360@manyfish.co.uk>
Message-ID: <200410122207.53698.nmav@gnutls.org>

On Thursday 07 October 2004 23:04, Joe Orton wrote:

> For a certificate with the OU encoded as a BMPString, the function
> appears to simply give back the raw UCS-2 data, likewise a T61String OU
> is given back as-is.
Could you provide me with a certificate of this kind?
Most probably the behaviour of gnutls would be to reject those certificates
for now.

> joe

-- 
Nikos Mavrogiannopoulos



From joe at manyfish.co.uk  Wed Oct 13 00:00:49 2004
From: joe at manyfish.co.uk (Joe Orton)
Date: Tue, 12 Oct 2004 23:00:49 +0100
Subject: [gnutls-dev] non-ASCII ASN.1 string types
In-Reply-To: <200410122207.53698.nmav@gnutls.org>
References: <20041007210455.GA29360@manyfish.co.uk>
	<200410122207.53698.nmav@gnutls.org>
Message-ID: <20041012220049.GB23899@manyfish.co.uk>

On Tue, Oct 12, 2004 at 10:07:53PM +0200, Nikos Mavrogiannopoulos wrote:
> On Thursday 07 October 2004 23:04, Joe Orton wrote:
> 
> > For a certificate with the OU encoded as a BMPString, the function
> > appears to simply give back the raw UCS-2 data, likewise a T61String OU
> > is given back as-is.
> Could you provide me with a certificate of this kind?
> Most probably the behaviour of gnutls would be to reject those certificates
> for now.

Attached certificates t61subj.cert and bmpsubj.cert in PEM format. You
can generate these using OpenSSL; the tests scripts I use in neon are:

http://svn.webdav.org/repos/projects/neon/trunk/test/makekeys.sh
http://svn.webdav.org/repos/projects/neon/trunk/test/openssl.conf

Regards,

joe
-------------- next part --------------
-----BEGIN CERTIFICATE-----
MIICVzCCAgGgAwIBAgIBADANBgkqhkiG9w0BAQQFADCBqjELMAkGA1UEBhMCR0Ix
FzAVBgNVBAgTDkNhbWJyaWRnZXNoaXJlMRIwEAYDVQQHEwlDYW1icmlkZ2UxGTAX
BgNVBAoTEE5lb24gSGFja2VycyBMdGQxHzAdBgNVBAseFgBIAOgAbABsAG8AIABX
AG8AcgBsAGQxEjAQBgNVBAMTCWxvY2FsaG9zdDEeMBwGCSqGSIb3DQEJARYPbmVv
bkB3ZWJkYXYub3JnMB4XDTA0MTAxMTE5NDYzNVoXDTA3MDMzMDE5NDYzNVowgaox
CzAJBgNVBAYTAkdCMRcwFQYDVQQIEw5DYW1icmlkZ2VzaGlyZTESMBAGA1UEBxMJ
Q2FtYnJpZGdlMRkwFwYDVQQKExBOZW9uIEhhY2tlcnMgTHRkMR8wHQYDVQQLHhYA
SADoAGwAbABvACAAVwBvAHIAbABkMRIwEAYDVQQDEwlsb2NhbGhvc3QxHjAcBgkq
hkiG9w0BCQEWD25lb25Ad2ViZGF2Lm9yZzBcMA0GCSqGSIb3DQEBAQUAA0sAMEgC
QQDzRU5sZ8+CWQPvPkqJw9KloEgT2FqzZR9RT/qbJuRBmRphiRr0g7JOh5Mr7LXa
KShedFLhGidutyKKwIZJnRhtAgMBAAGjEDAOMAwGA1UdEwQFMAMBAf8wDQYJKoZI
hvcNAQEEBQADQQCaumgmqYb9CbipMffiOv9CHRX9VWk/2tnkZ9XgwZnyfnep/iBC
QBfAxamdAAynLQxJXnmDLXTPZq3GRssFBxN8
-----END CERTIFICATE-----
-------------- next part --------------
-----BEGIN CERTIFICATE-----
MIICQTCCAeugAwIBAgIBADANBgkqhkiG9w0BAQQFADCBnzELMAkGA1UEBhMCR0Ix
FzAVBgNVBAgTDkNhbWJyaWRnZXNoaXJlMRIwEAYDVQQHEwlDYW1icmlkZ2UxGTAX
BgNVBAoTEE5lb24gSGFja2VycyBMdGQxFDASBgNVBAsUC0jobGxvIFdvcmxkMRIw
EAYDVQQDEwlsb2NhbGhvc3QxHjAcBgkqhkiG9w0BCQEWD25lb25Ad2ViZGF2Lm9y
ZzAeFw0wNDEwMTExOTQ2MzVaFw0wNzAzMzAxOTQ2MzVaMIGfMQswCQYDVQQGEwJH
QjEXMBUGA1UECBMOQ2FtYnJpZGdlc2hpcmUxEjAQBgNVBAcTCUNhbWJyaWRnZTEZ
MBcGA1UEChMQTmVvbiBIYWNrZXJzIEx0ZDEUMBIGA1UECxQLSOhsbG8gV29ybGQx
EjAQBgNVBAMTCWxvY2FsaG9zdDEeMBwGCSqGSIb3DQEJARYPbmVvbkB3ZWJkYXYu
b3JnMFwwDQYJKoZIhvcNAQEBBQADSwAwSAJBAPNFTmxnz4JZA+8+SonD0qWgSBPY
WrNlH1FP+psm5EGZGmGJGvSDsk6HkyvstdopKF50UuEaJ263IorAhkmdGG0CAwEA
AaMQMA4wDAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQQFAANBAMWMqJ4IxmrL+saJ
6MNjJNqaoMU/ANSZuEDrvA0312z8E/PfsJRcyMvFx5gkYSGVxC2/d8olqgM783Na
NKW/l0w=
-----END CERTIFICATE-----

From nmav at gnutls.org  Wed Oct 13 11:34:56 2004
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 13 Oct 2004 11:34:56 +0200
Subject: [gnutls-dev] non-ASCII ASN.1 string types
In-Reply-To: <20041012220049.GB23899@manyfish.co.uk>
References: <20041007210455.GA29360@manyfish.co.uk>
	<200410122207.53698.nmav@gnutls.org>
	<20041012220049.GB23899@manyfish.co.uk>
Message-ID: <200410131134.56539.nmav@gnutls.org>

On Wednesday 13 October 2004 00:00, Joe Orton wrote:
> On Tue, Oct 12, 2004 at 10:07:53PM +0200, Nikos Mavrogiannopoulos wrote:
> > On Thursday 07 October 2004 23:04, Joe Orton wrote:
> > > For a certificate with the OU encoded as a BMPString, the function
> > > appears to simply give back the raw UCS-2 data, likewise a T61String OU
> > > is given back as-is.
> > Could you provide me with a certificate of this kind?
> > Most probably the behaviour of gnutls would be to reject those
> > certificates for now.
> Attached certificates t61subj.cert and bmpsubj.cert in PEM format. You
> can generate these using OpenSSL; the tests scripts I use in neon are:
Ok. The newest patch will print something like:
Subject: C=GB,ST=Cambridgeshire,L=Cambridge,O=Neon Hackers 
Ltd,OU=#48e86c6c6f20576f726c64,CN=localhost,EMAIL=neon at webdav.org

for these certificates.

> Regards,
> joe

-- 
Nikos Mavrogiannopoulos



From jas at extundo.com  Fri Oct 15 22:31:18 2004
From: jas at extundo.com (Simon Josefsson)
Date: Fri, 15 Oct 2004 22:31:18 +0200
Subject: [gnutls-dev] CVS statistics
Message-ID: <ilu8ya7vi3t.fsf@latte.josefsson.org>

Hello.  Something to read on a Friday night:

http://josefsson.org/gnutls/statcvs/

Enjoy,
Simon




From joe at manyfish.co.uk  Sun Oct 17 12:08:26 2004
From: joe at manyfish.co.uk (Joe Orton)
Date: Sun, 17 Oct 2004 11:08:26 +0100
Subject: [gnutls-dev] non-ASCII ASN.1 string types
In-Reply-To: <200410131134.56539.nmav@gnutls.org>
References: <20041007210455.GA29360@manyfish.co.uk>
	<200410122207.53698.nmav@gnutls.org>
	<20041012220049.GB23899@manyfish.co.uk>
	<200410131134.56539.nmav@gnutls.org>
Message-ID: <20041017100826.GA1107@manyfish.co.uk>

On Wed, Oct 13, 2004 at 11:34:56AM +0200, Nikos Mavrogiannopoulos wrote:
> On Wednesday 13 October 2004 00:00, Joe Orton wrote:
> > On Tue, Oct 12, 2004 at 10:07:53PM +0200, Nikos Mavrogiannopoulos wrote:
> > > On Thursday 07 October 2004 23:04, Joe Orton wrote:
> > > > For a certificate with the OU encoded as a BMPString, the function
> > > > appears to simply give back the raw UCS-2 data, likewise a T61String OU
> > > > is given back as-is.
> > > Could you provide me with a certificate of this kind?
> > > Most probably the behaviour of gnutls would be to reject those
> > > certificates for now.
> > Attached certificates t61subj.cert and bmpsubj.cert in PEM format. You
> > can generate these using OpenSSL; the tests scripts I use in neon are:
> Ok. The newest patch will print something like:
> Subject: C=GB,ST=Cambridgeshire,L=Cambridge,O=Neon Hackers 
> Ltd,OU=#48e86c6c6f20576f726c64,CN=localhost,EMAIL=neon at webdav.org

I dunno, I'd rather the functions fail if the RDN can't be
auto-converted into UTF-8 per the docs (but UCS-2->UTF-8 is a simple
conversion anyway).

On this subject: is there a way to iterate over all the RDNs in the
subject or issuer DN using GNU TLS?  neon needs to produce
human-readable DNs - this is easy using OpenSSL's X509_NAME interface,
but I can't find a way of doing it in GNU TLS.  Can anyone help? 

joe



From nmav at gnutls.org  Sun Oct 17 12:46:30 2004
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 17 Oct 2004 12:46:30 +0200
Subject: [gnutls-dev] non-ASCII ASN.1 string types
In-Reply-To: <20041017100826.GA1107@manyfish.co.uk>
References: <20041007210455.GA29360@manyfish.co.uk>
	<200410131134.56539.nmav@gnutls.org>
	<20041017100826.GA1107@manyfish.co.uk>
Message-ID: <200410171246.31052.nmav@gnutls.org>

On Sunday 17 October 2004 12:08, Joe Orton wrote:

> > Ok. The newest patch will print something like:
> > Subject: C=GB,ST=Cambridgeshire,L=Cambridge,O=Neon Hackers
> > Ltd,OU=#48e86c6c6f20576f726c64,CN=localhost,EMAIL=neon at webdav.org
> I dunno, I'd rather the functions fail if the RDN can't be
> auto-converted into UTF-8 per the docs
I don't like this behaviour. And according to my intrerpretation of rfc2253, 
this is the proper thing to do when an unsupported character set is found in 
the asn.1 encoding.

> (but UCS-2->UTF-8 is a simple 
> conversion anyway).
But not simple enough. Maybe in a later version a callback is used so that the 
caller can do the string conversion himself.


> On this subject: is there a way to iterate over all the RDNs in the
> subject or issuer DN using GNU TLS?  neon needs to produce
> human-readable DNs - this is easy using OpenSSL's X509_NAME interface,
> but I can't find a way of doing it in GNU TLS.  Can anyone help?
Yes. You can use:
gnutls_x509_crt_get_dn_by_oid()
after calling gnutls_x509_crt_get_dn_oid() to get all OIDs in the DN.

> joe

-- 
Nikos Mavrogiannopoulos



From joe at manyfish.co.uk  Sun Oct 17 13:55:06 2004
From: joe at manyfish.co.uk (Joe Orton)
Date: Sun, 17 Oct 2004 12:55:06 +0100
Subject: [gnutls-dev] non-ASCII ASN.1 string types
In-Reply-To: <200410171246.31052.nmav@gnutls.org>
References: <20041007210455.GA29360@manyfish.co.uk>
	<200410131134.56539.nmav@gnutls.org>
	<20041017100826.GA1107@manyfish.co.uk>
	<200410171246.31052.nmav@gnutls.org>
Message-ID: <20041017115506.GB1107@manyfish.co.uk>

On Sun, Oct 17, 2004 at 12:46:30PM +0200, Nikos Mavrogiannopoulos wrote:
> On Sunday 17 October 2004 12:08, Joe Orton wrote:
> 
> > > Ok. The newest patch will print something like:
> > > Subject: C=GB,ST=Cambridgeshire,L=Cambridge,O=Neon Hackers
> > > Ltd,OU=#48e86c6c6f20576f726c64,CN=localhost,EMAIL=neon at webdav.org
> > I dunno, I'd rather the functions fail if the RDN can't be
> > auto-converted into UTF-8 per the docs
> I don't like this behaviour. And according to my intrerpretation of rfc2253, 
> this is the proper thing to do when an unsupported character set is found in 
> the asn.1 encoding.

Well I guess the interface is simply not flexible enough for this to be
decided by the app, where ultimately it should be.  I have no need for
2253-style formatting in neon, I'd prefer to be able to skip RDNs which
I can't produce human-readable strings from than show random hex strings
to the user.
 
> > On this subject: is there a way to iterate over all the RDNs in the
> > subject or issuer DN using GNU TLS?  neon needs to produce
> > human-readable DNs - this is easy using OpenSSL's X509_NAME interface,
> > but I can't find a way of doing it in GNU TLS.  Can anyone help?
> Yes. You can use:
> gnutls_x509_crt_get_dn_by_oid()
> after calling gnutls_x509_crt_get_dn_oid() to get all OIDs in the DN.

Ah, yes, I couldn't work out at all what _get_dn_oid was putting the
passed-in buffer.  Can you explain how the OIDs are formatted in the
buffer, or give an example of how I'd do this?

Thanks for your responses!

Regards,

joe



From nmav at gnutls.org  Sun Oct 17 15:03:57 2004
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 17 Oct 2004 15:03:57 +0200
Subject: [gnutls-dev] non-ASCII ASN.1 string types
In-Reply-To: <20041017115506.GB1107@manyfish.co.uk>
References: <20041007210455.GA29360@manyfish.co.uk>
	<200410171246.31052.nmav@gnutls.org>
	<20041017115506.GB1107@manyfish.co.uk>
Message-ID: <200410171503.57614.nmav@gnutls.org>

On Sunday 17 October 2004 13:55, Joe Orton wrote:

> Well I guess the interface is simply not flexible enough for this to be
> decided by the app, where ultimately it should be.  I have no need for
> 2253-style formatting in neon, I'd prefer to be able to skip RDNs which
> I can't produce human-readable strings from than show random hex strings
> to the user.
Well UCS-2 and UCS-4 certificates are quite rare to come by so in most of the
cases you have a readable string. 

> Ah, yes, I couldn't work out at all what _get_dn_oid was putting the
> passed-in buffer.  Can you explain how the OIDs are formatted in the
> buffer, or give an example of how I'd do this?
I don't have an example but in brief you call _get_dn_oid() using a counter
for index. For value 0 of the counter you get the first OID, which will be 
something like 1.2.3.4.5 (null terminated string).
You use this OID to get_dn_by_oid() function with indx==0 to  get the actual 
string.

In some certificates there could be a duplicate entry of an OID. In that case
you should increase the index number to get_dn_by_oid() to get the second
entry.

> Regards,
>
> joe

-- 
Nikos Mavrogiannopoulos



From joe at manyfish.co.uk  Sun Oct 17 16:26:27 2004
From: joe at manyfish.co.uk (Joe Orton)
Date: Sun, 17 Oct 2004 15:26:27 +0100
Subject: [gnutls-dev] non-ASCII ASN.1 string types
In-Reply-To: <200410171503.57614.nmav@gnutls.org>
References: <20041007210455.GA29360@manyfish.co.uk>
	<200410171246.31052.nmav@gnutls.org>
	<20041017115506.GB1107@manyfish.co.uk>
	<200410171503.57614.nmav@gnutls.org>
Message-ID: <20041017142627.GA31616@manyfish.co.uk>

On Sun, Oct 17, 2004 at 03:03:57PM +0200, Nikos Mavrogiannopoulos wrote:
> On Sunday 17 October 2004 13:55, Joe Orton wrote:
> 
> > Well I guess the interface is simply not flexible enough for this to be
> > decided by the app, where ultimately it should be.  I have no need for
> > 2253-style formatting in neon, I'd prefer to be able to skip RDNs which
> > I can't produce human-readable strings from than show random hex strings
> > to the user.
> Well UCS-2 and UCS-4 certificates are quite rare to come by so in most of the
> cases you have a readable string. 
> 
> > Ah, yes, I couldn't work out at all what _get_dn_oid was putting the
> > passed-in buffer.  Can you explain how the OIDs are formatted in the
> > buffer, or give an example of how I'd do this?
> I don't have an example but in brief you call _get_dn_oid() using a counter
> for index. For value 0 of the counter you get the first OID, which will be 
> something like 1.2.3.4.5 (null terminated string).

So the void *oid parameter is really just supposed to be a preallocated
char array into which the OID is written out as a NUL-terminated dotted
decimal string?  For me it doesn't seem to put anything in the oid
buffer at all, it just updates the length parameter.  Am I doing
something wrong?  The lengths look right if they don't include the NUL
terminator, from countryName -> strlen(2.5.4.6) == 7 to emailAddress ->
strlen(1.2.840.113549.1.9.1) == 20.

The scratch code I'm trying is below:

    int ret, idx = 0;

    do {
        char oid[32] = {0};
        size_t oidlen = sizeof oid;
        
        ret = name->subject 
            ? gnutls_x509_crt_get_dn_oid(name->cert, idx, oid, &oidlen)
            : gnutls_x509_crt_get_issuer_dn_oid(name->cert, idx, oid, &oidlen);
        
        if (ret == 0) {
            NE_DEBUG(NE_DBG_SSL, "got oid idx %d, len = %u: [%.*s]: ", 
                     idx, oidlen, (int)oidlen, oid);
            NE_DEBUG(NE_DBG_SSL, "oid[0..3] is 0x%x 0x%x 0x%x 0x%x\n",
                     ((int)oid[0]),
                     ((int)oid[1]),
                     ((int)oid[2]),
                     ((int)oid[3]));
            idx++;
        }
    } while (ret != GNUTLS_E_REQUESTED_DATA_NOT_AVAILABLE);

the debugging output is:

got oid idx 0, len = 7: []: oid[0..3] is 0x0 0x0 0x0 0x0
got oid idx 1, len = 7: []: oid[0..3] is 0x0 0x0 0x0 0x0
got oid idx 2, len = 7: []: oid[0..3] is 0x0 0x0 0x0 0x0
got oid idx 3, len = 8: []: oid[0..3] is 0x0 0x0 0x0 0x0
got oid idx 4, len = 8: []: oid[0..3] is 0x0 0x0 0x0 0x0
got oid idx 5, len = 7: []: oid[0..3] is 0x0 0x0 0x0 0x0
got oid idx 6, len = 20: []: oid[0..3] is 0x0 0x0 0x0 0x0




From joe at manyfish.co.uk  Sun Oct 17 21:43:17 2004
From: joe at manyfish.co.uk (Joe Orton)
Date: Sun, 17 Oct 2004 20:43:17 +0100
Subject: [gnutls-dev] [PATCH] add --la-file to *-config scripts
Message-ID: <20041017194317.GB16350@manyfish.co.uk>

It's preferable to able to link directly against the appropriate .la
files from a project using libtool: this patch adds --la-file arguments
to the *-config scripts to expose the location of the .la files to allow
this.

Index: lib/libgnutls-config.in
===================================================================
RCS file: /cvs/gnutls/gnutls/lib/libgnutls-config.in,v
retrieving revision 2.4
diff -u -r2.4 libgnutls-config.in
--- lib/libgnutls-config.in	20 May 2002 10:43:35 -0000	2.4
+++ lib/libgnutls-config.in	17 Oct 2004 19:37:56 -0000
@@ -6,6 +6,7 @@
 
 gnutls_libs="@LIBGNUTLS_LIBS@"
 gnutls_cflags="@LIBGNUTLS_CFLAGS@"
+gnutls_la_file="@libdir@/libgnutls.la"
 
 usage()
 {
@@ -58,6 +59,9 @@
     --libs)
       echo_libs=yes
       ;;
+    --la-file)
+      echo_la_file=yes
+      ;;
     *)
       usage 1 1>&2
       ;;
@@ -83,6 +87,10 @@
       done
     fi
     echo $includes $gnutls_cflags
+fi
+
+if test "$echo_la_file" = "yes"; then
+    echo ${gnutls_la_file}
 fi
 
 if test "$echo_libs" = "yes"; then
Index: libextra/libgnutls-extra-config.in
===================================================================
RCS file: /cvs/gnutls/gnutls/libextra/libgnutls-extra-config.in,v
retrieving revision 1.1
diff -u -r1.1 libgnutls-extra-config.in
--- libextra/libgnutls-extra-config.in	20 May 2002 12:51:02 -0000	1.1
+++ libextra/libgnutls-extra-config.in	17 Oct 2004 19:37:56 -0000
@@ -6,6 +6,7 @@
 
 gnutls_libs="@LIBGNUTLS_EXTRA_LIBS@"
 gnutls_cflags="@LIBGNUTLS_EXTRA_CFLAGS@"
+gnutls_la_file="@libdir@/libgnutls-extra.la"
 
 usage()
 {
@@ -58,6 +59,9 @@
     --libs)
       echo_libs=yes
       ;;
+    --la-file)
+      echo_la_file=yes
+      ;;
     *)
       usage 1 1>&2
       ;;
@@ -83,6 +87,10 @@
       done
     fi
     echo $includes $gnutls_cflags
+fi
+
+if test "$echo_la_file" = "yes"; then
+    echo ${gnutls_la_file}
 fi
 
 if test "$echo_libs" = "yes"; then





From aleix at member.fsf.org  Tue Oct 19 00:21:10 2004
From: aleix at member.fsf.org (Aleix Conchillo Flaque)
Date: Tue, 19 Oct 2004 00:21:10 +0200
Subject: [gnutls-dev] unencrypted PKCS#12
Message-ID: <878ya38y7d.fsf@googy.org>

Hi,

I'm playing around opening some PKCS#12 files and I've found something
curious. When PKCS#12s are not encrypted:

- gnutls_pkcs12_bag_decrypt(bag, "") works, but if I pass a NULL I get
  a segmentation fault.

- gnutls_x509_privkey_import_pkcs8(key, &key_data, GNUTLS_X509_FMT_DER,
                                   NULL, 0)
  here if I pass an empty password "" instead of NULL I get an
  GNUTLS_E_MPI_SCAN_FAILED error (The scanning of a large integer has
  failed).

Which is the correct way to use this? I've make it work just trying,
but is not specified anywhere. Or may be I missed something.

Thanks in advance.

Regards,

aleix




From nmav at gnutls.org  Tue Oct 19 23:00:05 2004
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Tue, 19 Oct 2004 23:00:05 +0200
Subject: [gnutls-dev] unencrypted PKCS#12
In-Reply-To: <878ya38y7d.fsf@googy.org>
References: <878ya38y7d.fsf@googy.org>
Message-ID: <200410192300.05196.nmav@gnutls.org>

On Tuesday 19 October 2004 00:21, Aleix Conchillo Flaque wrote:
> Hi,
Hello Aleix,
 
> I'm playing around opening some PKCS#12 files and I've found something
> curious. When PKCS#12s are not encrypted:
> - gnutls_pkcs12_bag_decrypt(bag, "") works, but if I pass a NULL I get
>   a segmentation fault.
I'll check it soon (I'm pretty stressed now with other things).
But anyway why do you want to decrypt a bag that is not encrypted?


> - gnutls_x509_privkey_import_pkcs8(key, &key_data, GNUTLS_X509_FMT_DER,
>                                    NULL, 0)
>   here if I pass an empty password "" instead of NULL I get an
>   GNUTLS_E_MPI_SCAN_FAILED error (The scanning of a large integer has
>   failed).
> Which is the correct way to use this? I've make it work just trying,
> but is not specified anywhere. Or may be I missed something.
I'll check it as soon that too. The only example currently for PKCS #12 is the
certtool utility (although it's code is a mess).

> Regards,
> aleix

-- 
Nikos Mavrogiannopoulos



From aleix at member.fsf.org  Tue Oct 19 23:15:14 2004
From: aleix at member.fsf.org (Aleix Conchillo Flaque)
Date: Tue, 19 Oct 2004 23:15:14 +0200
Subject: [gnutls-dev] unencrypted PKCS#12
In-Reply-To: <200410192300.05196.nmav@gnutls.org> (Nikos Mavrogiannopoulos's
	message of "Tue, 19 Oct 2004 23:00:05 +0200")
References: <878ya38y7d.fsf@googy.org> <200410192300.05196.nmav@gnutls.org>
Message-ID: <87zn2i76l9.fsf@googy.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

>> - gnutls_pkcs12_bag_decrypt(bag, "") works, but if I pass a NULL I get
>>   a segmentation fault.
> I'll check it soon (I'm pretty stressed now with other things).
> But anyway why do you want to decrypt a bag that is not encrypted?
>

Because I don't know if it is encrypted or not. For example, if I
don't use this function with empty password I get a
GNUTLS_BAG_ENCRYPTED type with the certificate bag with an unencrypted
PKCS#12.

> I'll check it as soon that too. The only example currently for PKCS #12 is the
> certtool utility (although it's code is a mess).
>

Ok. Don't worry, take your time :).

Thanks for the answer.

regards,

aleix




From nmav at gnutls.org  Wed Oct 20 00:06:13 2004
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 20 Oct 2004 00:06:13 +0200
Subject: [gnutls-dev] unencrypted PKCS#12
In-Reply-To: <87zn2i76l9.fsf@googy.org>
References: <878ya38y7d.fsf@googy.org> <200410192300.05196.nmav@gnutls.org>
	<87zn2i76l9.fsf@googy.org>
Message-ID: <200410200006.13801.nmav@gnutls.org>

On Tuesday 19 October 2004 23:15, Aleix Conchillo Flaque wrote:

> >> - gnutls_pkcs12_bag_decrypt(bag, "") works, but if I pass a NULL I get
> >>   a segmentation fault.
> > I'll check it soon (I'm pretty stressed now with other things).
> > But anyway why do you want to decrypt a bag that is not encrypted?
> Because I don't know if it is encrypted or not. For example, if I
> don't use this function with empty password I get a
> GNUTLS_BAG_ENCRYPTED type with the certificate bag with an unencrypted
> PKCS#12.
Do you use gnutls_pkcs12_bag_get_type()? In that function you must also 
specify the index of the bag element to check. Certtool makes use of this 
function and seems to work.

> regards,
> aleix

-- 
Nikos Mavrogiannopoulos



From aleix at member.fsf.org  Wed Oct 20 00:12:03 2004
From: aleix at member.fsf.org (Aleix Conchillo Flaque)
Date: Wed, 20 Oct 2004 00:12:03 +0200
Subject: [gnutls-dev] unencrypted PKCS#12
In-Reply-To: <200410200006.13801.nmav@gnutls.org> (Nikos Mavrogiannopoulos's
	message of "Wed, 20 Oct 2004 00:06:13 +0200")
References: <878ya38y7d.fsf@googy.org> <200410192300.05196.nmav@gnutls.org>
	<87zn2i76l9.fsf@googy.org> <200410200006.13801.nmav@gnutls.org>
Message-ID: <87sm8a73yk.fsf@googy.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> Do you use gnutls_pkcs12_bag_get_type()? In that function you must also 
> specify the index of the bag element to check. Certtool makes use of this 
> function and seems to work.
>

Yes, I use that function which is where I get that the unencrypted
certificate bag is encrypted.

aleix




From nmav at gnutls.org  Wed Oct 20 00:17:31 2004
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 20 Oct 2004 00:17:31 +0200
Subject: [gnutls-dev] unencrypted PKCS#12
In-Reply-To: <87sm8a73yk.fsf@googy.org>
References: <878ya38y7d.fsf@googy.org> <200410200006.13801.nmav@gnutls.org>
	<87sm8a73yk.fsf@googy.org>
Message-ID: <200410200017.31609.nmav@gnutls.org>

On Wednesday 20 October 2004 00:12, Aleix Conchillo Flaque wrote:
> Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
> > Do you use gnutls_pkcs12_bag_get_type()? In that function you must also
> > specify the index of the bag element to check. Certtool makes use of this
> > function and seems to work.
> Yes, I use that function which is where I get that the unencrypted
> certificate bag is encrypted.
Maybe you should check if "certtool --p12-info" correctly parses your p12 
structure. If it does then there should be a problem in your code. Otherwise
there should be a problem in my code :)

In the latter case I'd appreciate if you could send me the p12 structure.

> aleix

-- 
Nikos Mavrogiannopoulos



From joe at manyfish.co.uk  Wed Oct 20 00:32:03 2004
From: joe at manyfish.co.uk (Joe Orton)
Date: Tue, 19 Oct 2004 23:32:03 +0100
Subject: [gnutls-dev] unencrypted PKCS#12
In-Reply-To: <200410200017.31609.nmav@gnutls.org>
References: <878ya38y7d.fsf@googy.org> <200410200006.13801.nmav@gnutls.org>
	<87sm8a73yk.fsf@googy.org> <200410200017.31609.nmav@gnutls.org>
Message-ID: <20041019223203.GB9354@manyfish.co.uk>

On Wed, Oct 20, 2004 at 12:17:31AM +0200, Nikos Mavrogiannopoulos wrote:
> Maybe you should check if "certtool --p12-info" correctly parses your p12 
> structure. If it does then there should be a problem in your code. Otherwise
> there should be a problem in my code :)
> 
> In the latter case I'd appreciate if you could send me the p12 structure.

I get:

Enter password: p12_import: Base64 decoding error.

for all the neon test certs, attached. 

client.p12 has password "foobar", unclient.p12 and noclient.p12 have
empty/no password, otherwise the certs are the same except noclient.p12 
doesn't have a friendly name.

joe

-------------- next part --------------
A non-text attachment was scrubbed...
Name: client.p12
Type: application/octet-stream
Size: 1444 bytes
Desc: not available
URL: </pipermail/attachments/20041019/6481afca/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: unclient.p12
Type: application/octet-stream
Size: 1476 bytes
Desc: not available
URL: </pipermail/attachments/20041019/6481afca/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: noclient.p12
Type: application/octet-stream
Size: 1317 bytes
Desc: not available
URL: </pipermail/attachments/20041019/6481afca/attachment-0002.obj>

From aleix at member.fsf.org  Thu Oct 21 00:51:07 2004
From: aleix at member.fsf.org (Aleix Conchillo Flaque)
Date: Thu, 21 Oct 2004 00:51:07 +0200
Subject: [gnutls-dev] [PATCH] certificates not initialised in
 gnutls_certificate_set_x509_trust
Message-ID: <87brex6m1w.fsf@googy.org>


Just a simple patch to solve a memory bug. _gnutls_x509_crt_cpy needs
the dst certificate to be initialised in gnutls_certificate_set_x509_trust.

aleix

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: gnutls_x509.diff
URL: </pipermail/attachments/20041021/1a370350/attachment.txt>

From jas at extundo.com  Sun Oct 24 15:54:20 2004
From: jas at extundo.com (Simon Josefsson)
Date: Sun, 24 Oct 2004 15:54:20 +0200
Subject: [gnutls-dev] Re: [PATCH] add --la-file to *-config scripts
References: <20041017194317.GB16350@manyfish.co.uk>
Message-ID: <iluy8hw8bn7.fsf@latte.josefsson.org>

Joe Orton <joe at manyfish.co.uk> writes:

> It's preferable to able to link directly against the appropriate .la
> files from a project using libtool: this patch adds --la-file arguments
> to the *-config scripts to expose the location of the .la files to allow
> this.

I have installed this for 1.0 and 1.1.

Thanks,
Simon




From jas at extundo.com  Sun Oct 24 16:32:14 2004
From: jas at extundo.com (Simon Josefsson)
Date: Sun, 24 Oct 2004 16:32:14 +0200
Subject: [gnutls-dev] Re: [PATCH] certificates not initialised in
	gnutls_certificate_set_x509_trust
References: <87brex6m1w.fsf@googy.org>
Message-ID: <ilur7no89w1.fsf@latte.josefsson.org>

Aleix Conchillo Flaque <aleix at member.fsf.org> writes:

> Just a simple patch to solve a memory bug. _gnutls_x509_crt_cpy needs
> the dst certificate to be initialised in gnutls_certificate_set_x509_trust.

I have installed this for 1.0 and 1.1.

Thanks,
Simon




From jas at extundo.com  Sun Oct 24 16:41:07 2004
From: jas at extundo.com (Simon Josefsson)
Date: Sun, 24 Oct 2004 16:41:07 +0200
Subject: [gnutls-dev] Re: unencrypted PKCS#12
References: <878ya38y7d.fsf@googy.org> <200410200006.13801.nmav@gnutls.org>
	<87sm8a73yk.fsf@googy.org> <200410200017.31609.nmav@gnutls.org>
	<20041019223203.GB9354@manyfish.co.uk>
Message-ID: <ilumzyc89h8.fsf@latte.josefsson.org>

Joe Orton <joe at manyfish.co.uk> writes:

> I get:
>
> Enter password: p12_import: Base64 decoding error.
>
> for all the neon test certs, attached. 

All files seem to work fine here.  Are you sure you were using the
--inder parameter?  As in:

jas at latte:~/src/gnutls$ src/certtool --p12-info --infile client.p12 --inder --password foobar
BAG #0
        Type: Encrypted
...

> client.p12 has password "foobar", unclient.p12 and noclient.p12 have
> empty/no password, otherwise the certs are the same except noclient.p12 
> doesn't have a friendly name.

Can we add your files to the self test suite, of the PKCS#12 parser?
I don't believe copyright assignment would be required.

Thanks,
Simon




From jas at extundo.com  Sun Oct 24 16:49:27 2004
From: jas at extundo.com (Simon Josefsson)
Date: Sun, 24 Oct 2004 16:49:27 +0200
Subject: [gnutls-dev] Re: non-ASCII ASN.1 string types
References: <20041007210455.GA29360@manyfish.co.uk>
	<200410131134.56539.nmav@gnutls.org>
	<20041017100826.GA1107@manyfish.co.uk>
	<200410171246.31052.nmav@gnutls.org>
	<20041017115506.GB1107@manyfish.co.uk>
Message-ID: <iluis90893c.fsf@latte.josefsson.org>

Joe Orton <joe at manyfish.co.uk> writes:

> On Sun, Oct 17, 2004 at 12:46:30PM +0200, Nikos Mavrogiannopoulos wrote:
>> On Sunday 17 October 2004 12:08, Joe Orton wrote:
>> 
>> > > Ok. The newest patch will print something like:
>> > > Subject: C=GB,ST=Cambridgeshire,L=Cambridge,O=Neon Hackers
>> > > Ltd,OU=#48e86c6c6f20576f726c64,CN=localhost,EMAIL=neon at webdav.org
>> > I dunno, I'd rather the functions fail if the RDN can't be
>> > auto-converted into UTF-8 per the docs
>> I don't like this behaviour. And according to my intrerpretation of rfc2253, 
>> this is the proper thing to do when an unsupported character set is found in 
>> the asn.1 encoding.
>
> Well I guess the interface is simply not flexible enough for this to be
> decided by the app, where ultimately it should be.  I have no need for
> 2253-style formatting in neon, I'd prefer to be able to skip RDNs which
> I can't produce human-readable strings from than show random hex strings
> to the user.

That is a worthy goal, and if you want to work on adding some
interface in GnuTLS, similar to the OpenSSL X509_NAME, to achieve it,
I think it could be incorporated.

For what it's worth, I agree with Nikos that adding UCS2->UTF8
conversion is to enter a problematic road.  For non-ASCII handling, I
believe that GnuTLS should use some external library, that is focused
on that problem.  There are so many pitfalls in charset handling that
I wouldn't want the GnuTLS code to have to deal with them too.  TLS is
complex enough as it is.  GNU Libidn can do charset conversion, but
there may be other candidates.

I'm sorry I don't have free time to help with the OID code you posted.
If you debug it further, and submit your code as a new self test
(possibly together with a patch to fix any bugs), I will try to work
on integrating it.

Thanks,
Simon




From joe at manyfish.co.uk  Sun Oct 24 17:19:45 2004
From: joe at manyfish.co.uk (Joe Orton)
Date: Sun, 24 Oct 2004 16:19:45 +0100
Subject: [gnutls-dev] Re: non-ASCII ASN.1 string types
In-Reply-To: <iluis90893c.fsf@latte.josefsson.org>
References: <20041007210455.GA29360@manyfish.co.uk>
	<200410131134.56539.nmav@gnutls.org>
	<20041017100826.GA1107@manyfish.co.uk>
	<200410171246.31052.nmav@gnutls.org>
	<20041017115506.GB1107@manyfish.co.uk>
	<iluis90893c.fsf@latte.josefsson.org>
Message-ID: <20041024151945.GA16375@manyfish.co.uk>

On Sun, Oct 24, 2004 at 04:49:27PM +0200, Simon Josefsson wrote:
> Joe Orton <joe at manyfish.co.uk> writes:
> > Well I guess the interface is simply not flexible enough for this to be
> > decided by the app, where ultimately it should be.  I have no need for
> > 2253-style formatting in neon, I'd prefer to be able to skip RDNs which
> > I can't produce human-readable strings from than show random hex strings
> > to the user.
> 
> That is a worthy goal, and if you want to work on adding some
> interface in GnuTLS, similar to the OpenSSL X509_NAME, to achieve it,
> I think it could be incorporated.

I doubt I will have time to work on this, sorry.

> For what it's worth, I agree with Nikos that adding UCS2->UTF8
> conversion is to enter a problematic road.  For non-ASCII handling, I
> believe that GnuTLS should use some external library, that is focused
> on that problem.  There are so many pitfalls in charset handling that
> I wouldn't want the GnuTLS code to have to deal with them too.  TLS is
> complex enough as it is.  GNU Libidn can do charset conversion, but
> there may be other candidates.
> 
> I'm sorry I don't have free time to help with the OID code you posted.
> If you debug it further, and submit your code as a new self test
> (possibly together with a patch to fix any bugs), I will try to work
> on integrating it.

It's OK, Nikos fixed that in CVS already.

joe



From joe at manyfish.co.uk  Sun Oct 24 17:46:28 2004
From: joe at manyfish.co.uk (Joe Orton)
Date: Sun, 24 Oct 2004 16:46:28 +0100
Subject: [gnutls-dev] unencrypted PKCS#12
In-Reply-To: <87sm8a73yk.fsf@googy.org>
References: <878ya38y7d.fsf@googy.org> <200410192300.05196.nmav@gnutls.org>
	<87zn2i76l9.fsf@googy.org> <200410200006.13801.nmav@gnutls.org>
	<87sm8a73yk.fsf@googy.org>
Message-ID: <20041024154628.GA26275@manyfish.co.uk>

On Wed, Oct 20, 2004 at 12:12:03AM +0200, Aleix Conchillo Flaque wrote:
> Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
> 
> > Do you use gnutls_pkcs12_bag_get_type()? In that function you must also 
> > specify the index of the bag element to check. Certtool makes use of this 
> > function and seems to work.
> >
> 
> Yes, I use that function which is where I get that the unencrypted
> certificate bag is encrypted.

I think this is right, Aleix: the bags really are encrypted, just using
a zero-length password string.  I've adjusted the neon code to verify
the MAC manually in both cases and it passes the load_client_cert tests
with the GnuTLS HEAD at least.

joe



From joe at manyfish.co.uk  Sun Oct 24 17:50:32 2004
From: joe at manyfish.co.uk (Joe Orton)
Date: Sun, 24 Oct 2004 16:50:32 +0100
Subject: [gnutls-dev] Re: unencrypted PKCS#12
In-Reply-To: <ilumzyc89h8.fsf@latte.josefsson.org>
References: <878ya38y7d.fsf@googy.org> <200410200006.13801.nmav@gnutls.org>
	<87sm8a73yk.fsf@googy.org> <200410200017.31609.nmav@gnutls.org>
	<20041019223203.GB9354@manyfish.co.uk>
	<ilumzyc89h8.fsf@latte.josefsson.org>
Message-ID: <20041024155032.GB26275@manyfish.co.uk>

On Sun, Oct 24, 2004 at 04:41:07PM +0200, Simon Josefsson wrote:
> Joe Orton <joe at manyfish.co.uk> writes:
> 
> > I get:
> >
> > Enter password: p12_import: Base64 decoding error.
> >
> > for all the neon test certs, attached. 
> 
> All files seem to work fine here.  Are you sure you were using the
> --inder parameter?  As in:

No, I wasn't. 

> jas at latte:~/src/gnutls$ src/certtool --p12-info --infile client.p12 --inder --password foobar
> BAG #0

Great, thanks.  Though this doesn't work with the GnuTLS 1.0.20 release
with unclient.p12 or noclient.p12, --password '' still prompts for a
password, I'm not sure whether this has been fixed in CVS on the 1.0
branch since.

> Can we add your files to the self test suite, of the PKCS#12 parser?

Yes, sure.

joe



From jas at extundo.com  Sun Oct 24 18:21:41 2004
From: jas at extundo.com (Simon Josefsson)
Date: Sun, 24 Oct 2004 18:21:41 +0200
Subject: [gnutls-dev] Re: unencrypted PKCS#12
References: <878ya38y7d.fsf@googy.org> <200410200006.13801.nmav@gnutls.org>
	<87sm8a73yk.fsf@googy.org> <200410200017.31609.nmav@gnutls.org>
	<20041019223203.GB9354@manyfish.co.uk>
	<ilumzyc89h8.fsf@latte.josefsson.org>
	<20041024155032.GB26275@manyfish.co.uk>
Message-ID: <iluekjo84tm.fsf@latte.josefsson.org>

Joe Orton <joe at manyfish.co.uk> writes:

>> jas at latte:~/src/gnutls$ src/certtool --p12-info --infile client.p12 --inder --password foobar
>> BAG #0
>
> Great, thanks.  Though this doesn't work with the GnuTLS 1.0.20 release
> with unclient.p12 or noclient.p12, --password '' still prompts for a
> password, I'm not sure whether this has been fixed in CVS on the 1.0
> branch since.

I fixed it for 1.1.18; I have back ported the fix to 1.0 in CVS now.

>> Can we add your files to the self test suite, of the PKCS#12 parser?
>
> Yes, sure.

They are used in 1.1.x now.

Thanks.




From nmav at gnutls.org  Wed Oct 27 08:07:22 2004
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 27 Oct 2004 08:07:22 +0200
Subject: [gnutls-dev] unencrypted PKCS#12
In-Reply-To: <878ya38y7d.fsf@googy.org>
References: <878ya38y7d.fsf@googy.org>
Message-ID: <200410270807.22284.nmav@gnutls.org>

On Tuesday 19 October 2004 00:21, Aleix Conchillo Flaque wrote:
> Hi,
>
> I'm playing around opening some PKCS#12 files and I've found something
> curious. When PKCS#12s are not encrypted:
>
> - gnutls_pkcs12_bag_decrypt(bag, "") works, but if I pass a NULL I get
>   a segmentation fault.
I think I fixed that. Now it should return an error.

> - gnutls_x509_privkey_import_pkcs8(key, &key_data, GNUTLS_X509_FMT_DER,
>                                    NULL, 0)
>   here if I pass an empty password "" instead of NULL I get an
>   GNUTLS_E_MPI_SCAN_FAILED error (The scanning of a large integer has
>   failed).
This is not really a bug. You cannot use empty passwords. Use the flag 
GNUTLS_PKCS_PLAIN or a NULL password instead, if you want to disable 
encryption.

> aleix

-- 
Nikos Mavrogiannopoulos



From joe at manyfish.co.uk  Wed Oct 27 09:04:37 2004
From: joe at manyfish.co.uk (Joe Orton)
Date: Wed, 27 Oct 2004 08:04:37 +0100
Subject: [gnutls-dev] unencrypted PKCS#12
In-Reply-To: <200410270807.22284.nmav@gnutls.org>
References: <878ya38y7d.fsf@googy.org> <200410270807.22284.nmav@gnutls.org>
Message-ID: <20041027070437.GA23351@manyfish.co.uk>

On Wed, Oct 27, 2004 at 08:07:22AM +0200, Nikos Mavrogiannopoulos wrote:
> On Tuesday 19 October 2004 00:21, Aleix Conchillo Flaque wrote:
> > Hi,
> >
> > I'm playing around opening some PKCS#12 files and I've found something
> > curious. When PKCS#12s are not encrypted:
> >
> > - gnutls_pkcs12_bag_decrypt(bag, "") works, but if I pass a NULL I get
> >   a segmentation fault.
> I think I fixed that. Now it should return an error.
> 
> > - gnutls_x509_privkey_import_pkcs8(key, &key_data, GNUTLS_X509_FMT_DER,
> >                                    NULL, 0)
> >   here if I pass an empty password "" instead of NULL I get an
> >   GNUTLS_E_MPI_SCAN_FAILED error (The scanning of a large integer has
> >   failed).
> This is not really a bug. You cannot use empty passwords. Use the flag 
> GNUTLS_PKCS_PLAIN or a NULL password instead, if you want to disable 
> encryption.

This has broken neon again!  The unclient.p12 certificate isn't readable
again now.  We had this working OK in neon with the old GNU TLS code.

joe



From nmav at gnutls.org  Wed Oct 27 12:08:24 2004
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Wed, 27 Oct 2004 12:08:24 +0200
Subject: [gnutls-dev] unencrypted PKCS#12
In-Reply-To: <20041027070437.GA23351@manyfish.co.uk>
References: <878ya38y7d.fsf@googy.org> <200410270807.22284.nmav@gnutls.org>
	<20041027070437.GA23351@manyfish.co.uk>
Message-ID: <200410271208.24491.nmav@gnutls.org>

On Wednesday 27 October 2004 09:04, Joe Orton wrote:

> > > - gnutls_pkcs12_bag_decrypt(bag, "") works, but if I pass a NULL I get
> > >   a segmentation fault.
> > I think I fixed that. Now it should return an error.
> This has broken neon again!  The unclient.p12 certificate isn't readable
> again now.  We had this working OK in neon with the old GNU TLS code.
I reverted the change then. However how was this p12 structure generated?
(using which program?)

> joe

-- 
Nikos Mavrogiannopoulos



From joe at manyfish.co.uk  Wed Oct 27 12:24:01 2004
From: joe at manyfish.co.uk (Joe Orton)
Date: Wed, 27 Oct 2004 11:24:01 +0100
Subject: [gnutls-dev] unencrypted PKCS#12
In-Reply-To: <200410271208.24491.nmav@gnutls.org>
References: <878ya38y7d.fsf@googy.org> <200410270807.22284.nmav@gnutls.org>
	<20041027070437.GA23351@manyfish.co.uk>
	<200410271208.24491.nmav@gnutls.org>
Message-ID: <20041027102401.GA11389@manyfish.co.uk>

On Wed, Oct 27, 2004 at 12:08:24PM +0200, Nikos Mavrogiannopoulos wrote:
> On Wednesday 27 October 2004 09:04, Joe Orton wrote:
> 
> > > > - gnutls_pkcs12_bag_decrypt(bag, "") works, but if I pass a NULL I get
> > > >   a segmentation fault.
> > > I think I fixed that. Now it should return an error.
> > This has broken neon again!  The unclient.p12 certificate isn't readable
> > again now.  We had this working OK in neon with the old GNU TLS code.
> I reverted the change then.

Thanks Nikos.

> However how was this p12 structure generated? (using which program?)

Just using openssl pkcs12, see the makekeys.sh from neon I referenced
earlier.  Mozilla imports these certs without prompting for a password
IIRC.

joe




From jas at extundo.com  Wed Oct 27 23:31:00 2004
From: jas at extundo.com (Simon Josefsson)
Date: Wed, 27 Oct 2004 23:31:00 +0200
Subject: [gnutls-dev] gnutls 1.1.21
Message-ID: <ilu654vonl7.fsf@latte.josefsson.org>

Hello.  This release include a few fixes.  GnuTLS still require
snprintf in libc, otherwise I'm not aware of any problems.

Oh.  I just realized I forgot to add one item to the NEWS entry below.
With this version, the GnuTLS GTK-DOC API manual is included in
Devhelp format.  It look the same as the GTK-DOC HTML output:

http://josefsson.org/gnutls/reference/

but with the Devhelp program you can search for functions quickly.  I
think there are some Emacs tools that make use of Devhelp files, too.

I believe in good documentation, but I have little time to read all
the generated formats carefully before each release.  I encourage
people to report problems with the manuals in the 1.1.x series, so
that 1.2.0 will ship with manuals in a good shape.  See the list of
formats furthest down on the following page:

http://josefsson.org/gnutls/documentation.html

Enjoy,
Simon

* Version 1.1.21 (2004-10-27)
- Print DN of certificates with unknown characters in them, but in hexform
  only.
- Added second precision to the X.509 parsing and generation functions.
- Corrected bug in _gnutls_x509_get_dn_oid(), and returns the
  actual OID.
- Add parameter --la-file to libgnutls-config and libgnutls-extra-config,
  tiny patch contributed by Joe Orton <joe at manyfish.co.uk>.
- Add pkg-config meta files, suggested by St?phane LOEUILLET
  <stephane.loeuillet at tiscali.fr>.
- Fix memory initializaion bug in gnutls_certificate_set_x509_trust,
  tiny patch by Aleix Conchillo Flaque <aleix at member.fsf.org>.
- Add self test of PKCS#12 functionality in "certtool", based on test
  vectors from Joe Orton <joe at manyfish.co.uk>.
- Fix library order in libgnutls*-config --libs output, to permit
  static linking, reported by Yoann Vandoorselaere
  <yoann at prelude-ids.org>.




From joe at manyfish.co.uk  Wed Oct 27 23:57:09 2004
From: joe at manyfish.co.uk (Joe Orton)
Date: Wed, 27 Oct 2004 22:57:09 +0100
Subject: [gnutls-dev] gnutls 1.1.21
In-Reply-To: <ilu654vonl7.fsf@latte.josefsson.org>
References: <ilu654vonl7.fsf@latte.josefsson.org>
Message-ID: <20041027215709.GA23278@manyfish.co.uk>

On Wed, Oct 27, 2004 at 11:31:00PM +0200, Simon Josefsson wrote:
> Hello.  This release include a few fixes.  GnuTLS still require
> snprintf in libc, otherwise I'm not aware of any problems.
> 
> Oh.  I just realized I forgot to add one item to the NEWS entry below.
> With this version, the GnuTLS GTK-DOC API manual is included in
> Devhelp format.  It look the same as the GTK-DOC HTML output:
> 
> http://josefsson.org/gnutls/reference/

That looks useful, thanks.  w.r.t. 
http://josefsson.org/gnutls/manual/html_node/index.html

is it possible to fix the ToC links to point to a useful #fragment
rather than e.g. all 3.x.y subtitles pointing to the same fragment as
the section 3 link itself?

Regards,

joe



From jas at extundo.com  Thu Oct 28 00:13:06 2004
From: jas at extundo.com (Simon Josefsson)
Date: Thu, 28 Oct 2004 00:13:06 +0200
Subject: [gnutls-dev] Re: gnutls 1.1.21
References: <ilu654vonl7.fsf@latte.josefsson.org>
	<20041027215709.GA23278@manyfish.co.uk>
Message-ID: <iluvfcvn72l.fsf@latte.josefsson.org>

Joe Orton <joe at manyfish.co.uk> writes:

> On Wed, Oct 27, 2004 at 11:31:00PM +0200, Simon Josefsson wrote:
>> Hello.  This release include a few fixes.  GnuTLS still require
>> snprintf in libc, otherwise I'm not aware of any problems.
>> 
>> Oh.  I just realized I forgot to add one item to the NEWS entry below.
>> With this version, the GnuTLS GTK-DOC API manual is included in
>> Devhelp format.  It look the same as the GTK-DOC HTML output:
>> 
>> http://josefsson.org/gnutls/reference/
>
> That looks useful, thanks.  w.r.t. 
> http://josefsson.org/gnutls/manual/html_node/index.html
>
> is it possible to fix the ToC links to point to a useful #fragment
> rather than e.g. all 3.x.y subtitles pointing to the same fragment as
> the section 3 link itself?

Right, that looks weird.  I suspect this is a bug in makeinfo; I'll
forward it upstream.

Thanks.




From jas at extundo.com  Thu Oct 28 12:49:42 2004
From: jas at extundo.com (Simon Josefsson)
Date: Thu, 28 Oct 2004 12:49:42 +0200
Subject: [gnutls-dev] gnutls 1.0.22
Message-ID: <iluzn27kth5.fsf@latte.josefsson.org>

Hello.  Similar bug fixes as in 1.1.21.

Enjoy,
Simon

Version 1.0.22 (28/10/2004)
- Print DN of certificates with unknown characters in them, but in hexform
  only.
- Corrected bug in _gnutls_x509_get_dn_oid(), and returns the
  actual OID.
- Added second precision to the X.509 parsing functions.
- Add parameter --la-file to libgnutls-config and libgnutls-extra-config,
  tiny patch contributed by Joe Orton <joe at manyfish.co.uk>.
- Add pkg-config meta files, suggested by St?phane LOEUILLET
  <stephane.loeuillet at tiscali.fr>.
- Fix memory initializaion bug in gnutls_certificate_set_x509_trust,
  tiny patch by Aleix Conchillo Flaque <aleix at member.fsf.org>.
- Fix certtool --password for PKCS #12, back ported from 1.1.x branch.
- Fix library order in libgnutls*-config --libs output, to permit
  static linking, reported by Yoann Vandoorselaere
  <yoann at prelude-ids.org>.




From joe at manyfish.co.uk  Thu Oct 28 14:09:59 2004
From: joe at manyfish.co.uk (Joe Orton)
Date: Thu, 28 Oct 2004 13:09:59 +0100
Subject: [gnutls-dev] gnutls 1.0.22
In-Reply-To: <iluzn27kth5.fsf@latte.josefsson.org>
References: <iluzn27kth5.fsf@latte.josefsson.org>
Message-ID: <20041028120959.GB10230@manyfish.co.uk>

On Thu, Oct 28, 2004 at 12:49:42PM +0200, Simon Josefsson wrote:
> Hello.  Similar bug fixes as in 1.1.21.

Thanks for the releases Simon!

I noticed that GNU TLS is using hand-crafted symbol version scripts for
GNU ld -- did you know that using libtool's -export-symbols{,-regex}
flags can be used to the same in a portable fashion?  It's rather neat.

joe



From jas at extundo.com  Thu Oct 28 15:11:22 2004
From: jas at extundo.com (Simon Josefsson)
Date: Thu, 28 Oct 2004 15:11:22 +0200
Subject: [gnutls-dev] Re: gnutls 1.0.22
References: <iluzn27kth5.fsf@latte.josefsson.org>
	<20041028120959.GB10230@manyfish.co.uk>
Message-ID: <iluekjjkmx1.fsf@latte.josefsson.org>

Joe Orton <joe at manyfish.co.uk> writes:

> On Thu, Oct 28, 2004 at 12:49:42PM +0200, Simon Josefsson wrote:
>> Hello.  Similar bug fixes as in 1.1.21.
>
> Thanks for the releases Simon!
>
> I noticed that GNU TLS is using hand-crafted symbol version scripts for
> GNU ld -- did you know that using libtool's -export-symbols{,-regex}
> flags can be used to the same in a portable fashion?  It's rather neat.

I am not that familiar with these features, I thought they all were
inherently unportable.  Not that it means they shouldn't be used, of
course, since they are useful for GNU systems.

Further thoughts on this?  Or preferably, specific patches...

Thanks.




From nmav at gnutls.org  Thu Oct 28 18:21:14 2004
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Thu, 28 Oct 2004 18:21:14 +0200
Subject: [gnutls-dev] gnutls 1.0.22
In-Reply-To: <20041028120959.GB10230@manyfish.co.uk>
References: <iluzn27kth5.fsf@latte.josefsson.org>
	<20041028120959.GB10230@manyfish.co.uk>
Message-ID: <200410281821.15079.nmav@gnutls.org>

On Thursday 28 October 2004 14:09, Joe Orton wrote:

> Thanks for the releases Simon!
> I noticed that GNU TLS is using hand-crafted symbol version scripts for
> GNU ld -- did you know that using libtool's -export-symbols{,-regex}
> flags can be used to the same in a portable fashion?  It's rather neat.
The last time I checked on libtool, it didn't use the GNU ld's features, and
the export-symbols was only working if I specified all the exported symbols
(which was not convenient).

> joe

-- 
Nikos Mavrogiannopoulos



From joe at manyfish.co.uk  Thu Oct 28 20:21:46 2004
From: joe at manyfish.co.uk (Joe Orton)
Date: Thu, 28 Oct 2004 19:21:46 +0100
Subject: [gnutls-dev] Re: gnutls 1.0.22
In-Reply-To: <iluekjjkmx1.fsf@latte.josefsson.org>
References: <iluzn27kth5.fsf@latte.josefsson.org>
	<20041028120959.GB10230@manyfish.co.uk>
	<iluekjjkmx1.fsf@latte.josefsson.org>
Message-ID: <20041028182146.GA26896@manyfish.co.uk>

On Thu, Oct 28, 2004 at 03:11:22PM +0200, Simon Josefsson wrote:
> Joe Orton <joe at manyfish.co.uk> writes:
> 
> > On Thu, Oct 28, 2004 at 12:49:42PM +0200, Simon Josefsson wrote:
> >> Hello.  Similar bug fixes as in 1.1.21.
> >
> > Thanks for the releases Simon!
> >
> > I noticed that GNU TLS is using hand-crafted symbol version scripts for
> > GNU ld -- did you know that using libtool's -export-symbols{,-regex}
> > flags can be used to the same in a portable fashion?  It's rather neat.
> 
> I am not that familiar with these features, I thought they all were
> inherently unportable.  Not that it means they shouldn't be used, of
> course, since they are useful for GNU systems.

It's supported on at least Solaris and AIX as well as with GNU ld; and
libtool just ignores it on platforms where it's not supported, so it's
OK.

> Further thoughts on this?  Or preferably, specific patches...

Patch below.  Attached list of symbols which get hidden in libgnutls.so
with this applied vs not using it at all, for verification: some of
these should probably get namespace-protected for systems on which
-export-symbols* isn't implemented: memmem, firstElement, bit_mask for
instance.

Index: configure.in
===================================================================
RCS file: /cvs/gnutls/gnutls/configure.in,v
retrieving revision 2.329
diff -u -r2.329 configure.in
--- configure.in	27 Oct 2004 21:29:32 -0000	2.329
+++ configure.in	28 Oct 2004 18:12:44 -0000
@@ -474,26 +474,6 @@
 ])
 AM_PROG_LIBTOOL
 
-dnl This is after AM_PROG_LIBTOOL so that the LD variable
-dnl has been set.
-
-AC_MSG_CHECKING([whether we have GNU ld or compatible])
-
-GLD=`$LD --help < /dev/null 2>/dev/null | grep version-script`
-if test "$GLD"; then
-have_ld_version_script=yes
-  AC_MSG_RESULT(yes)
-else
-have_ld_version_script=no
-  AC_MSG_RESULT(no)
-AC_MSG_WARN(***
-*** You may want to rerun configure using --with-gnu-ld to enable versioned symbols.
-)
-fi
-
-AM_CONDITIONAL(HAVE_LD_VERSION_SCRIPT, test "$have_ld_version_script" = "yes")
-
-
 LIBGNUTLS_LIBS="-L${libdir} -lgnutls $LIBTASN1_LIBS $LIBGCRYPT_LIBS $LIBS"
 LIBGNUTLS_CFLAGS="$LIBGCRYPT_CFLAGS $LIBTASN1_CFLAGS -I${includedir}"
 
Index: lib/Makefile.am
===================================================================
RCS file: /cvs/gnutls/gnutls/lib/Makefile.am,v
retrieving revision 2.148
diff -u -r2.148 Makefile.am
--- lib/Makefile.am	24 Oct 2004 14:12:08 -0000	2.148
+++ lib/Makefile.am	28 Oct 2004 18:12:44 -0000
@@ -9,11 +9,7 @@
 pkgconfig_DATA = gnutls.pc
 DISTCLEANFILES = $(pkgconfig_DATA)
 
-if HAVE_LD_VERSION_SCRIPT
-  libgnutls_version_script_cmd = -Wl,--version-script=$(srcdir)/libgnutls.vers
-else
-  libgnutls_version_script_cmd =
-endif
+LIBGNUTLS_EXPORTS = -export-symbols-regex '^(_gnutls|gnutls|_E_).*'
 
 DIST_SUBDIRS = minitasn1 x509
 if ENABLE_MINITASN1
@@ -79,7 +75,7 @@
 
 libgnutls_la_LDFLAGS = $(LIBTASN1_LIBS) $(LIBGCRYPT_LIBS) \
 	../crypto/libgc.la \
-	$(libgnutls_version_script_cmd) \
+	$(LIBGNUTLS_EXPORTS) \
 	-version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE)
 
 pkix_asn1_tab.c: pkix.asn
Index: libextra/Makefile.am
===================================================================
RCS file: /cvs/gnutls/gnutls/libextra/Makefile.am,v
retrieving revision 1.51
diff -u -r1.51 Makefile.am
--- libextra/Makefile.am	24 Oct 2004 14:12:09 -0000	1.51
+++ libextra/Makefile.am	28 Oct 2004 18:12:44 -0000
@@ -10,11 +10,7 @@
 pkgconfig_DATA = gnutls-extra.pc
 DISTCLEANFILES = $(pkgconfig_DATA)
 
-if HAVE_LD_VERSION_SCRIPT
-  libgnutls_extra_version_script_cmd = -Wl,--version-script=$(srcdir)/libgnutls-extra.vers
-else
-  libgnutls_extra_version_script_cmd =
-endif
+LIBGNUTLS_EXTRA_EXPORTS = -export-symbols-regex '^gnutls.*'
 
 EXTRA_DIST = libgnutls-extra.vers \
 	openssl_compat.h gnutls-extra-api.texi \
@@ -70,7 +66,7 @@
 	gnutls_extra.c
 
 
-libgnutls_extra_la_LDFLAGS = $(libgnutls_extra_version_script_cmd) \
+libgnutls_extra_la_LDFLAGS = $(LIBGNUTLS_EXTRA_EXPORTS) \
 	-version-info $(LT_CURRENT):$(LT_REVISION):$(LT_AGE) \
 	$(LIBOPENCDK_LIBS) $(LZO_LIBS)
 
-------------- next part --------------
anon_auth_struct
_asn1_add_node
_asn1_add_node_only
_asn1_append_sequence_set
asn1_array2tree
_asn1_bit_der
_asn1_change_integer_value
_asn1_check_identifier
asn1_check_version
_asn1_complete_explicit_tag
_asn1_convert_integer
_asn1_copy_structure2
_asn1_copy_structure3
asn1_create_element
_asn1_create_static_structure
asn1_delete_element
_asn1_delete_list
_asn1_delete_list_and_nodes
_asn1_delete_not_used
asn1_delete_structure
asn1_der_coding
asn1_der_decoding
asn1_der_decoding_element
asn1_der_decoding_startEnd
_asn1_error_description_tag_error
_asn1_error_description_value_not_found
asn1_expand_any_defined_by
_asn1_expand_identifier
_asn1_expand_object_id
asn1_expand_octet_string
_asn1_extract_tag_der
_asn1_find_left
_asn1_find_node
asn1_find_structure_from_oid
_asn1_find_up
_asn1_get_bit_der
_asn1_get_down
_asn1_get_indefinite_length_string
_asn1_get_last_right
_asn1_get_length_der
_asn1_get_name
_asn1_get_objectid_der
_asn1_get_octet_der
_asn1_get_octet_string
_asn1_get_right
_asn1_get_tag_der
_asn1_get_time_der
_asn1_hierarchical_name
_asn1_identifierMissing
_asn1_insert_tag_der
_asn1_length_der
_asn1_ltostr
_asn1_mem_cpy
_asn1_mod_type
asn1_number_of_elements
_asn1_objectid_der
_asn1_octet_der
_asn1_ordering_set
_asn1_ordering_set_of
asn1_print_structure
asn1_read_tag
asn1_read_value
_asn1_remove_node
_asn1_set_default_tag
_asn1_set_down
_asn1_set_name
_asn1_set_right
_asn1_set_value
_asn1_str_cat
_asn1_str_cpy
_asn1_tag_der
_asn1_time_der
_asn1_type_choice_config
_asn1_type_set_config
asn1_write_value
bit_mask
__bss_start
dhe_dss_auth_struct
dhe_rsa_auth_struct
_edata
_end
_fini
firstElement
gc_cipher_close
gc_cipher_decrypt_inline
gc_cipher_encrypt_inline
gc_cipher_open
gc_cipher_setiv
gc_cipher_setkey
gc_done
gc_hash_buffer
gc_hash_clone
gc_hash_close
gc_hash_digest_length
gc_hash_hmac_setkey
gc_hash_open
gc_hash_read
gc_hash_write
gc_hmac_md5
gc_hmac_sha1
gc_init
gc_md5
gc_nonce
gc_pkcs5_pbkdf2_sha1
gc_pseudo_random
gc_random
gc_set_allocators
_init
libtasn1_perror
libtasn1_strerror
memmem
_pkcs12_decode_crt_bag
_pkcs12_decode_safe_contents
_pkcs12_encode_crt_bag
_pkcs12_encode_safe_contents
_pkcs12_string_to_key
pkix_asn1_tab
rsa_auth_struct
rsa_export_auth_struct
srp_auth_struct
srp_dss_auth_struct
srp_rsa_auth_struct

From joe at manyfish.co.uk  Thu Oct 28 20:23:01 2004
From: joe at manyfish.co.uk (Joe Orton)
Date: Thu, 28 Oct 2004 19:23:01 +0100
Subject: [gnutls-dev] gnutls 1.0.22
In-Reply-To: <200410281821.15079.nmav@gnutls.org>
References: <iluzn27kth5.fsf@latte.josefsson.org>
	<20041028120959.GB10230@manyfish.co.uk>
	<200410281821.15079.nmav@gnutls.org>
Message-ID: <20041028182301.GB26896@manyfish.co.uk>

On Thu, Oct 28, 2004 at 06:21:14PM +0200, Nikos Mavrogiannopoulos wrote:
> On Thursday 28 October 2004 14:09, Joe Orton wrote:
> 
> > Thanks for the releases Simon!
> > I noticed that GNU TLS is using hand-crafted symbol version scripts for
> > GNU ld -- did you know that using libtool's -export-symbols{,-regex}
> > flags can be used to the same in a portable fashion?  It's rather neat.
> The last time I checked on libtool, it didn't use the GNU ld's features, and
> the export-symbols was only working if I specified all the exported symbols
> (which was not convenient).

Yup, that was fixed in libtool 1.5.

joe



From jas at extundo.com  Thu Oct 28 22:50:23 2004
From: jas at extundo.com (Simon Josefsson)
Date: Thu, 28 Oct 2004 22:50:23 +0200
Subject: [gnutls-dev] Re: gnutls 1.0.22
References: <iluzn27kth5.fsf@latte.josefsson.org>
	<20041028120959.GB10230@manyfish.co.uk>
	<iluekjjkmx1.fsf@latte.josefsson.org>
	<20041028182146.GA26896@manyfish.co.uk>
Message-ID: <iluvfcuk1o0.fsf@latte.josefsson.org>

Joe Orton <joe at manyfish.co.uk> writes:

>> Further thoughts on this?  Or preferably, specific patches...
>
> Patch below.  Attached list of symbols which get hidden in libgnutls.so
> with this applied vs not using it at all, for verification: some of
> these should probably get namespace-protected for systems on which
> -export-symbols* isn't implemented: memmem, firstElement, bit_mask for
> instance.

I'm not familiar with these issues enough to decide whether the patch
will work or not.  Nikos?  Are there any shared library or libtool
experts on the list with an opinion?

Since your patch remove several things that I consider cruft, I'm
positive about it, FWIW.

I guess we will find out if the patch works if we apply it...

Thanks.




From nmav at gnutls.org  Fri Oct 29 10:54:51 2004
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Fri, 29 Oct 2004 10:54:51 +0200
Subject: [gnutls-dev] Re: gnutls 1.0.22
In-Reply-To: <iluvfcuk1o0.fsf@latte.josefsson.org>
References: <iluzn27kth5.fsf@latte.josefsson.org>
	<20041028182146.GA26896@manyfish.co.uk>
	<iluvfcuk1o0.fsf@latte.josefsson.org>
Message-ID: <200410291054.51333.nmav@gnutls.org>

On Thursday 28 October 2004 22:50, Simon Josefsson wrote:
> Joe Orton <joe at manyfish.co.uk> writes:
> >> Further thoughts on this?  Or preferably, specific patches...
> >
> > Patch below.  Attached list of symbols which get hidden in libgnutls.so
> > with this applied vs not using it at all, for verification: some of
> > these should probably get namespace-protected for systems on which
> > -export-symbols* isn't implemented: memmem, firstElement, bit_mask for
> > instance.
>
> I'm not familiar with these issues enough to decide whether the patch
> will work or not.  Nikos?  Are there any shared library or libtool
> experts on the list with an opinion?
It seems to address the problems I had with libtool so far.
I think it is better to adopt it.

> Thanks.

-- 
Nikos Mavrogiannopoulos



From jas at extundo.com  Fri Oct 29 11:04:13 2004
From: jas at extundo.com (Simon Josefsson)
Date: Fri, 29 Oct 2004 11:04:13 +0200
Subject: [gnutls-dev] Re: gnutls 1.0.22
References: <iluzn27kth5.fsf@latte.josefsson.org>
	<20041028182146.GA26896@manyfish.co.uk>
	<iluvfcuk1o0.fsf@latte.josefsson.org>
	<200410291054.51333.nmav@gnutls.org>
Message-ID: <ilud5z1ki9e.fsf@latte.josefsson.org>

Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:

> On Thursday 28 October 2004 22:50, Simon Josefsson wrote:
>> Joe Orton <joe at manyfish.co.uk> writes:
>> >> Further thoughts on this?  Or preferably, specific patches...
>> >
>> > Patch below.  Attached list of symbols which get hidden in libgnutls.so
>> > with this applied vs not using it at all, for verification: some of
>> > these should probably get namespace-protected for systems on which
>> > -export-symbols* isn't implemented: memmem, firstElement, bit_mask for
>> > instance.
>>
>> I'm not familiar with these issues enough to decide whether the patch
>> will work or not.  Nikos?  Are there any shared library or libtool
>> experts on the list with an opinion?
> It seems to address the problems I had with libtool so far.
> I think it is better to adopt it.

I'll add it,
Thanks.




From morth at morth.org  Fri Oct 29 00:30:24 2004
From: morth at morth.org (Pelle Johansson)
Date: Fri, 29 Oct 2004 00:30:24 +0200
Subject: [gnutls-dev] =?iso-8859-1?q?Problem_with_subject_names=2E_=28=C4?=
 =?iso-8859-1?q?ndrat_av_Pelle_Johansson=29?=
Message-ID: <38F10BF6-29A1-11D9-971B-000D93B08F9A@morth.org>

[Tried to join and send this to help-gnutls but it seems to be broken?]

I'm having some problem with the subject name extraction functions. I 
want to extract the common name from a certificate using 
gnutls_x509_crt_get_dn_by_oid(), but I'm always getting a 
GNUTLS_E_SHORT_MEMORY_BUFFER. This is regardless if I call with a NULL 
buf argument or with buf_sizeof set to 10000.

So to investigate some more I tried the gnutls_x509_crt_get_dn_oid() 
functions. These do set the size, but the buffer isn't filled out (it 
keeps it previous value). gnutls_x509_crt_get_dn() works as expected 
though.

Am I doing something wrong here or is there a bug?

Code:
const char *tls_get_cn (gnutls_x509_crt cert)
{
   size_t sz = 0;
   char *buf;
   int i;

   buf = malloc (10000);
   sz = 10000;
   if (!gnutls_x509_crt_get_dn (cert, buf, &sz))
     fprintf (stderr, "DN: %s\n", buf);
   sz = 10000;
   buf[0] = 0;
   for (i = 0; !gnutls_x509_crt_get_dn_oid (cert, i, buf, &sz); i++)
   {
     fprintf (stderr, "%d size %lu: %s\n", i, sz, buf);
     sz = 10000;
     buf[0] = 0;
   }

   sz = 10000;
   i = gnutls_x509_crt_get_dn_by_oid (cert, GNUTLS_OID_X520_COMMON_NAME, 
0, 0, NULL, &sz);
   fprintf (stderr, "res = %d, sz = %lu\n", i, sz);
   i = gnutls_x509_crt_get_dn_by_oid (cert, GNUTLS_OID_X520_COMMON_NAME, 
0, 0, buf, &sz);
   fprintf (stderr, "res = %d, sz = %lu\n", i, sz);
   if (i)
     return NULL;
   return buf;
}

Output:
DN: C=SE,L=Link?ping,O=morth.org,CN=ftp.morth.org,EMAIL=root at morth.org
0 size 7:
1 size 7:
2 size 8:
3 size 7:
4 size 20:
res = -51, sz = 0
res = -51, sz = 0
-- 
Pelle Johansson
<morth at morth.org>




From jas at extundo.com  Fri Oct 29 14:12:32 2004
From: jas at extundo.com (Simon Josefsson)
Date: Fri, 29 Oct 2004 14:12:32 +0200
Subject: [gnutls-dev] Re: gnutls 1.0.22
References: <iluzn27kth5.fsf@latte.josefsson.org>
	<20041028120959.GB10230@manyfish.co.uk>
	<iluekjjkmx1.fsf@latte.josefsson.org>
	<20041028182146.GA26896@manyfish.co.uk>
Message-ID: <iluzn25iuz3.fsf@latte.josefsson.org>

Joe Orton <joe at manyfish.co.uk> writes:

> Patch below.

Now added, thanks!

If you send more patches, I think we'll need copyright assignment for
your work.  Contact me off-list if you are willing to do this.

> Attached list of symbols which get hidden in libgnutls.so
> with this applied vs not using it at all, for verification: some of
> these should probably get namespace-protected for systems on which
> -export-symbols* isn't implemented: memmem, firstElement, bit_mask for
> instance.

Right, added to doc/TODO.




From joe at manyfish.co.uk  Fri Oct 29 14:40:23 2004
From: joe at manyfish.co.uk (Joe Orton)
Date: Fri, 29 Oct 2004 13:40:23 +0100
Subject: [gnutls-dev] Re: gnutls 1.0.22
In-Reply-To: <iluzn25iuz3.fsf@latte.josefsson.org>
References: <iluzn27kth5.fsf@latte.josefsson.org>
	<20041028120959.GB10230@manyfish.co.uk>
	<iluekjjkmx1.fsf@latte.josefsson.org>
	<20041028182146.GA26896@manyfish.co.uk>
	<iluzn25iuz3.fsf@latte.josefsson.org>
Message-ID: <20041029124023.GA1972@manyfish.co.uk>

On Fri, Oct 29, 2004 at 02:12:32PM +0200, Simon Josefsson wrote:
> Joe Orton <joe at manyfish.co.uk> writes:
> 
> > Patch below.
> 
> Now added, thanks!
> 
> If you send more patches, I think we'll need copyright assignment for
> your work.  Contact me off-list if you are willing to do this.

I'm a Red Hat employee and we have a corporate assignment with the FSF
already, so that should cover anything I contribute.

joe



From jas at extundo.com  Sat Oct 30 12:04:47 2004
From: jas at extundo.com (Simon Josefsson)
Date: Sat, 30 Oct 2004 12:04:47 +0200
Subject: [gnutls-dev] Re: Problem linking gnutls 1.0.16
In-Reply-To: <Pine.SOC.4.60.0407212002240.4215@blade.simplesystems.org> (Bob
	Friesenhahn's message of "Wed, 21 Jul 2004 20:07:19 -0500 (CDT)")
References: <Pine.SOC.4.60.0407212002240.4215@blade.simplesystems.org>
Message-ID: <iluhdocwmgw.fsf@latte.josefsson.org>

Bob Friesenhahn <bfriesen at simple.dallas.tx.us> wrote long time ago:

> I am building gnutls and friends on a Solaris 9 system with gcc 3.4.1, 
> using the Solaris linker.
...

In gnutls 1.1.x in CVS, I have now reverted to using libtool
convenience libraries, rather than to build files from one directory
only.  It builds for me on sparc-sun-solaris2.9 with GCC 3.3.2 and the
Solaris linker.  If it won't work for you, I think we should debug
this as a Libtool problem.  Libtool is supposed to handle this, and I
haven't had problems with Libtool convenience libraries on any
platform before [with modern libtool versions].

Thanks.



From nmav at gnutls.org  Sun Oct 31 11:19:12 2004
From: nmav at gnutls.org (Nikos Mavrogiannopoulos)
Date: Sun, 31 Oct 2004 11:19:12 +0100
Subject: [gnutls-dev] Problem with subject names.
	(=?iso-8859-1?q?=C4ndrat_av_Pelle?= Johansson)
In-Reply-To: <38F10BF6-29A1-11D9-971B-000D93B08F9A@morth.org>
References: <38F10BF6-29A1-11D9-971B-000D93B08F9A@morth.org>
Message-ID: <200410311119.13213.nmav@gnutls.org>

On Friday 29 October 2004 00:30, Pelle Johansson wrote:

> I'm having some problem with the subject name extraction functions. I
> want to extract the common name from a certificate using
> gnutls_x509_crt_get_dn_by_oid(), but I'm always getting a
> GNUTLS_E_SHORT_MEMORY_BUFFER. This is regardless if I call with a NULL
> buf argument or with buf_sizeof set to 10000.
Does this happen with the latest gnutls? (that is 1.0.22)

-- 
Nikos Mavrogiannopoulos