headers
Dash Shendy | 6 Jun 2011 19:59

Would like to contribute to mod_gnutls

Hi Nikos,

I hope that all is well.  I see that you have released a new bug-fix version of GnuTLS, great work!

While I was debugging that compression error, I had a look at the mod_gnutls module and it seemed a pretty straight forward implementation of GnuTLS library as an apache module, I would like to help out with maintaining the module.

I have been reading this tut <http://www.apachetutor.org/dev/config> on apache module dev.
Would you be so kind as to provide me with any relevant tutorials you might have, just to get me started?

In short, my question is:
Q) what skills does one require to develop mod_gnutls sanely?

I can think of the following:
  • Apache Module Development
  • GnuTLS internals
Your help is, as always, much appreciated.

Thanks,
Dash Shendy 
_______________________________________________
Help-gnutls mailing list
Help-gnutls <at> gnu.org
https://lists.gnu.org/mailman/listinfo/help-gnutls
Permalink | Reply | 1 comment |
headers
Nikos Mavrogiannopoulos | 7 Jun 2011 07:40

Re: Would like to contribute to mod_gnutls

On 06/06/2011 07:59 PM, Dash Shendy wrote:

> While I was debugging that compression error, I had a look at the
> mod_gnutls module and it seemed a pretty straight forward implementation
> of GnuTLS library as an apache module, I would like to help out with
> maintaining the module.

I've replied off-list.

regards,
Nikos
Permalink | Reply | 0 comments |
headers
Nikos Mavrogiannopoulos | 8 Jun 2011 13:36

roadmap for 3.0.0

Hello,
 The last commit by Stef Walter concludes the list of changes I
planned for gnutls 3.0.0. Those in brief were:
* Addition of Datagram TLS 1.0 (RFC4347)
* Addition of Elliptic curve ciphersuites (RFC4492)
* Addition of ECDSA for X.509 certificates (RFC5480,RFC5758)
* Addition of SuiteB profile (RFC5430)
* Addition of AES-GCM cipher (RFC5288)
* Addition of hardware optimized AES and AES-GCM on CPU's that support it
* Addition of a simple X.509 certificate verification subsystem
(gnutls_x509_trust_list_*)
* Addition of an auditing subsystem (gnutls_global_set_audit_log_function())
* Addition of a certificate retrieval function that requires no
processing from gnutls (gnutls_certificate_set_retrieve_function2())
* Usage of p11-kit for PKCS #11 support
* Removal of several deprecated features

The documentation has also been extended to discuss the new features,
and was also reorganized. If you think something is missing from this
list, or other things such as bug-fixes that should have made through,
but didn't please let me know.

As things stand and provided that there will be a release of nettle
with the GCM support included, I'll release 2.99.3 within this month
and that should be considered a prerelease of 3.0.0. The license of
gnutls 3.0.0 would be GNU LGPL version 3.

regards,
Nikos

_______________________________________________
Help-gnutls mailing list
Help-gnutls <at> gnu.org
https://lists.gnu.org/mailman/listinfo/help-gnutls
Permalink | Reply | 6 comments |
headers
Brad Hards | 8 Jun 2011 22:46

Re: roadmap for 3.0.0

On Wed, 8 Jun 2011 09:36:10 PM Nikos Mavrogiannopoulos wrote:
> The license of gnutls 3.0.0 would be GNU LGPL version 3.
Can you explain the rationale for this?

My concern is that there is some software that is stuck on GPL v2 (only), and 
LGPLv2 is compatible with that, but LGPLv3 is not. Poppler is a library that 
comes to mind, where it is often linked to (L)GPLv2+ code in tools like Evince 
and Okular (amongst others), and everything reverts back to GPLv2.

Would a LGPLv3 / GPLv2 license be acceptable here?

Brad
Permalink | Reply | 3 comments |
headers
Nikos Mavrogiannopoulos | 9 Jun 2011 00:46

Re: roadmap for 3.0.0

On 06/08/2011 10:46 PM, Brad Hards wrote:
> On Wed, 8 Jun 2011 09:36:10 PM Nikos Mavrogiannopoulos wrote:
>> The license of gnutls 3.0.0 would be GNU LGPL version 3.
> Can you explain the rationale for this?
> 
> My concern is that there is some software that is stuck on GPL v2 
> (only), and LGPLv2 is compatible with that, but LGPLv3 is not. 
> Poppler is a library that comes to mind, where it is often linked to 
> (L)GPLv2+ code in tools like Evince and Okular (amongst others), and 
> everything reverts back to GPLv2. Would a LGPLv3 / GPLv2 license be 
> acceptable here?

We thought about that, but it wouldn't be adequate. That is because gmp
that now gnutls is linked to, is LGPLv3. Even if we allow dual
license gmp doesn't. Note however that the problem is not in LGPLv3
which allows linking with everything, even proprietary programs. It is
GPLv2-only that causes the issue. It can be easily solved by the
authors of GPLv2-only programs by allowing linking with an
LGPLv3 library (see [0]).

regards,
Nikos

[0]. http://price.sourceforge.net/exception.html
Permalink | Reply | 2 comments |
headers
Brad Hards | 9 Jun 2011 11:38

Re: roadmap for 3.0.0

On Thursday 09 June 2011 08:46:20 Nikos Mavrogiannopoulos wrote:
> We thought about that, but it wouldn't be adequate. That is because gmp
> that now gnutls is linked to, is LGPLv3. Even if we allow dual
> license gmp doesn't. Note however that the problem is not in LGPLv3
> which allows linking with everything, even proprietary programs. It is
> GPLv2-only that causes the issue. It can be easily solved by the
> authors of GPLv2-only programs by allowing linking with an
> LGPLv3 library (see [0]).
Unfortunately the poppler code is based on xpdf code, for which the original 
author does not appear willing to relicense. The poppler additions are GPLv2+.

Is there any scope for asking gmp to do GPLv2/LGPLv3+? Is that the only issue?

Brad
Permalink | Reply | 1 comment |
headers
Nikos Mavrogiannopoulos | 9 Jun 2011 11:57

Re: roadmap for 3.0.0

On Thu, Jun 9, 2011 at 11:38 AM, Brad Hards <bradh <at> frogmouth.net> wrote:

>> We thought about that, but it wouldn't be adequate. That is because gmp
>> that now gnutls is linked to, is LGPLv3. Even if we allow dual
>> license gmp doesn't. Note however that the problem is not in LGPLv3
>> which allows linking with everything, even proprietary programs. It is
>> GPLv2-only that causes the issue. It can be easily solved by the
>> authors of GPLv2-only programs by allowing linking with an
>> LGPLv3 library (see [0]).
> Unfortunately the poppler code is based on xpdf code, for which the original
> author does not appear willing to relicense.

A re-license to GPLv3 is not really necessary. An exception to the
license to allow
linking to LGPLv3 libraries would be. This is a very sad situation, as
the problem
GnuTLS was solving (the need for openssl library exceptions) is now introduced
by GnuTLS itself on GPLv2-only projects.

> The poppler additions are GPLv2+.
> Is there any scope for asking gmp to do GPLv2/LGPLv3+? Is that the only issue?

We have already asked gmp and they didn't seem to be willing for the
relicense. I'd suggest to contact licensing <at> fsf.org, not so to get a
solution, but mostly to make them know this is a real problem they
need to work on.

I don't know how I can help here. For us dual-licensing to
GPLv2/LGPLv3+ would be possible, if all the libraries in the chain
(now only gmp) do the same. This is not an easy choice from the
library makers also, since such a dual-license would prohibit them
from copying code from plain LGPLv3+ projects.

regards,
Nikos
Permalink | Reply | 0 comments |
headers
Sebastian Kolbe | 11 Jun 2011 00:15
Picon

Support for PKCS12 client certificate files

Hello
I'm having trouble reading / importing a p12 certificate file (with public/private key for
client authentication). I used the function "gnutls_pkcs12_import" for this, but without
success.  Error message was "base64 decode error" (or similar).
Changing some of the other parameters (crt format, flags) only brought
different error messages.
At last the comand line tool (certtool) produced the same error message.
Version of library was 2.8.6 (standard in ubuntu) and 2.12.6.1 (latest available
for download).

I tried on command line with:
  certtool  --p12-info --infile cert.p12
(The certificate itself is ok, the tools "pk12util" from NSS and openSSL were able to
open the file and presenting all stored certificates.)

Is there something I can do here? Is there a error in syntax or is some more initialization
needed in prior? Or are PKCS12 files not fully supported?
BTW: the documentation is very "skinny" at this point...

Thank you in advance

Sebastian




_______________________________________________
Help-gnutls mailing list
Help-gnutls <at> gnu.org
https://lists.gnu.org/mailman/listinfo/help-gnutls
Permalink | Reply | 1 comment |
headers
Nikos Mavrogiannopoulos | 11 Jun 2011 09:08

Re: Support for PKCS12 client certificate files

On 06/11/2011 12:15 AM, Sebastian Kolbe wrote:
> Hello
> I'm having trouble reading / importing a p12 certificate file (with
> public/private key for
> client authentication). I used the function "gnutls_pkcs12_import" for this,
> but without
> success.  Error message was "base64 decode error" (or similar).

So you get a base64 decode error? Is your PKCS12 file base64 encoded?
Did you try the GNUTLS_X509_FMT_DER flag?

> Changing some of the other parameters (crt format, flags) only brought
> different error messages.
> At last the comand line tool (certtool) produced the same error message.
> Version of library was 2.8.6 (standard in ubuntu) and 2.12.6.1 (latest
> available
> for download).
> 
> I tried on command line with:
>   certtool  --p12-info --infile cert.p12

Try adding --inder option if your pkcs12 file is not
base64 encoded.

> BTW: the documentation is very "skinny" at this point...

Suggestions and patches are always welcome.

regards,
Nikos
Permalink | Reply | 0 comments |
headers
Michael Cronenworth | 13 Jun 2011 18:22

random blocking under Windows XP

Hello,

I am using GnuTLS as a transport layer for an XMLRPC-like interface. The 
program is a cross-platform client that speaks to a Linux server.

Using GnuTLS 2.8, I did not have any problems with communication. Upon 
recently upgrading to 2.10 I am seeing blocking under Windows XP 32-bit 
clients. I have tested thoroughly under Windows 7 64-bit and 32-bit and 
do not see blocking. My Linux clients do not see blocking either. The 
blocking happens randomly. Sometimes the client is never blocked the 
entire time the client is running. Other times the first write/read 
operation blocks. When the blocking occurs and I view the server, the 
server had already sent its data back and was waiting for the client's 
next move.

The following is a backtrace taken with the client is blocked:
(gdb) bt
#0  0x7c90e514 in ntdll!LdrAccessResource () from 
C:\WINDOWS\system32\ntdll.dll
#1  0x7c90df5a in ntdll!ZwWaitForSingleObject () from 
C:\WINDOWS\system32\ntdll.dll
#2  0x71a5402b in ?? () from C:\WINDOWS\system32\mswsock.dll
#3  0x71a557c9 in ?? () from C:\WINDOWS\system32\mswsock.dll
#4  0x71ab67de in WSACancelAsyncRequest () from 
C:\WINDOWS\system32\ws2_32.dll
#5  0x66784525 in ?? ()
    from C:\Documents and 
Settings\mcronenworth\Desktop\2011-06-13-win32\bin\libgnutls-26.dll
#6  0x66784d5e in ?? ()
    from C:\Documents and 
Settings\mcronenworth\Desktop\2011-06-13-win32\bin\libgnutls-26.dll
#7  0x667818a3 in ?? ()
    from C:\Documents and 
Settings\mcronenworth\Desktop\2011-06-13-win32\bin\libgnutls-26.dll
#8  0x6678293f in ?? ()
    from C:\Documents and 
Settings\mcronenworth\Desktop\2011-06-13-win32\bin\libgnutls-26.dll
(snipped to remove proprietary functions, but the 9th frame was a call 
to gnutls_record_recv())

Each time it blocks, it is in the WSACancelAsyncRequest() function.

My compile environment is Fedora 15 x86_64 with mingw32-gnutls-2.10.5 
installed. Any help would be appreciated.

Thanks,
Michael
Permalink | Reply | 3 comments |

Gmane