From ramkumar.chinchani at gmail.com  Mon Jan 13 00:58:21 2014
From: ramkumar.chinchani at gmail.com (Ramkumar Chinchani)
Date: Sun, 12 Jan 2014 23:58:21 +0000
Subject: [mod_gnutls-devel] Patch to fix configure script
Message-ID: <CANCUUtAMOobgu+mK1VGPWwRZkweXZS0G_w7hNf3jXDeo4TVZMw@mail.gmail.com>

diff --git a/configure.ac b/configure.ac
index 86259fa..6e30578 100644
--- a/configure.ac
+++ b/configure.ac
@@ -27,7 +27,7 @@ CHECK_APACHE(,$AP_VERSION,
     AC_MSG_ERROR([*** Apache version $AP_VERSION not found!])
 )

-PKG_CHECK_MODULES(LIBGNUTLS, [gnutls >= 2.12.6])
+PKG_CHECK_MODULES([LIBGNUTLS], [gnutls >= 2.12.6])

 LIBGNUTLS_VERSION=`pkg-config --modversion gnutls`
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140112/f4f240e0/attachment.html>

From dkg at fifthhorseman.net  Mon Jan 13 05:33:14 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 12 Jan 2014 23:33:14 -0500
Subject: [mod_gnutls-devel] Patch to fix configure script
In-Reply-To: <CANCUUtAMOobgu+mK1VGPWwRZkweXZS0G_w7hNf3jXDeo4TVZMw@mail.gmail.com>
References: <CANCUUtAMOobgu+mK1VGPWwRZkweXZS0G_w7hNf3jXDeo4TVZMw@mail.gmail.com>
Message-ID: <52D36C8A.805@fifthhorseman.net>

On 01/12/2014 06:58 PM, Ramkumar Chinchani wrote:
> diff --git a/configure.ac b/configure.ac
> index 86259fa..6e30578 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -27,7 +27,7 @@ CHECK_APACHE(,$AP_VERSION,
>      AC_MSG_ERROR([*** Apache version $AP_VERSION not found!])
>  )
> 
> -PKG_CHECK_MODULES(LIBGNUTLS, [gnutls >= 2.12.6])
> +PKG_CHECK_MODULES([LIBGNUTLS], [gnutls >= 2.12.6])
> 
>  LIBGNUTLS_VERSION=`pkg-config --modversion gnutls`

Thanks, applied.

Out of curiosity, what toolchain (and what versions, and what arguments)
were you using that this was a problem for you?  what were the error
messages?

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140112/473b8b48/attachment.sig>

From ramkumar.chinchani at gmail.com  Mon Jan 13 09:49:45 2014
From: ramkumar.chinchani at gmail.com (Ramkumar Chinchani)
Date: Mon, 13 Jan 2014 08:49:45 +0000
Subject: [mod_gnutls-devel] Patch to fix configure script
In-Reply-To: <52D36C8A.805@fifthhorseman.net>
References: <CANCUUtAMOobgu+mK1VGPWwRZkweXZS0G_w7hNf3jXDeo4TVZMw@mail.gmail.com>
 <52D36C8A.805@fifthhorseman.net>
Message-ID: <CANCUUtAc087Wbz+NcKad8-pk1pG5D9v6-pK1zv=gafBmMAEQxA@mail.gmail.com>

Building against Debian "wheezy" (and the corresponding toolchain) and
following the instructions on the project website.

checking for Apache 2.0 version >= 2.0.40... yes
Use of uninitialized value $includedir in concatenation (.) or string at
(eval 9) line 1.
checking whether DEFAULT_EXP_LIBEXECDIR is declared... no
./configure: line 11923: syntax error near unexpected token `LIBGNUTLS,'
./configure: line 11923: `PKG_CHECK_MODULES(LIBGNUTLS, gnutls >= 2.12.6)'




On Mon, Jan 13, 2014 at 4:33 AM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net>wrote:

> On 01/12/2014 06:58 PM, Ramkumar Chinchani wrote:
> > diff --git a/configure.ac b/configure.ac
> > index 86259fa..6e30578 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -27,7 +27,7 @@ CHECK_APACHE(,$AP_VERSION,
> >      AC_MSG_ERROR([*** Apache version $AP_VERSION not found!])
> >  )
> >
> > -PKG_CHECK_MODULES(LIBGNUTLS, [gnutls >= 2.12.6])
> > +PKG_CHECK_MODULES([LIBGNUTLS], [gnutls >= 2.12.6])
> >
> >  LIBGNUTLS_VERSION=`pkg-config --modversion gnutls`
>
> Thanks, applied.
>
> Out of curiosity, what toolchain (and what versions, and what arguments)
> were you using that this was a problem for you?  what were the error
> messages?
>
> Regards,
>
>         --dkg
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140113/06a539f0/attachment.html>

From BenBE at geshi.org  Mon Jan 13 09:52:45 2014
From: BenBE at geshi.org (Benny Baumann)
Date: Mon, 13 Jan 2014 09:52:45 +0100
Subject: [mod_gnutls-devel] Support for OCSP stapling?
Message-ID: <52D3A95D.9030406@geshi.org>

Hi,

Are there plans to implement OCSP stapling in mod_gnutls?

What are the places that need to be looked into to do the necessary setup?

Regards,
BenBE.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140113/c3687b7b/attachment.sig>

From dkg at fifthhorseman.net  Tue Jan 21 01:48:31 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 20 Jan 2014 19:48:31 -0500
Subject: [mod_gnutls-devel] Support for OCSP stapling?
In-Reply-To: <52D3A95D.9030406@geshi.org>
References: <52D3A95D.9030406@geshi.org>
Message-ID: <52DDC3DF.20606@fifthhorseman.net>

On 01/13/2014 03:52 AM, Benny Baumann wrote:

> Are there plans to implement OCSP stapling in mod_gnutls?

I have no immediate plans for OCSP stapling in mod_gnutls (i'm still
trying to carve out time for a proper release with some of the newer
authentication features), but would be happy to see it added.

For those searching for it in the codebase, OCSP stapling is known
formally as an OCSP status request. see:

  https://tools.ietf.org/html/rfc6066#section-8

> What are the places that need to be looked into to do the necessary setup?

Modern versions of the GnuTLS library (since 3.1, i think) already have
OCSP functionality, so we'd just need to hook into that in mod_gnutls.

The simplest minimal approach would be to add a configuration parameter
to indicate the file to read the OCSP response from using:

 gnutls_certificate_set_ocsp_status_request_file()

and then rely on the server operator to update that file regularly with
something like this (e.g. from cron or a systemd timer file):

ocsptool --ask --load-cert server_cert.pem --load-issuer the_issuer.pem
         --load-signer the_issuer.pem --outfile ocsp.response


This is probably somewhat inefficient on high-traffic servers, but it
would provide a functioning implementation, and a more complex
in-process caching/re-fetching architecture could be built later.

Would this baseline implementation be useful for you?

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20140120/489c8235/attachment-0001.sig>

From BenBE at geshi.org  Tue Jan 21 17:48:29 2014
From: BenBE at geshi.org (Benny Baumann)
Date: Tue, 21 Jan 2014 17:48:29 +0100
Subject: [mod_gnutls-devel] Support for OCSP stapling?
In-Reply-To: <52DDC3DF.20606@fifthhorseman.net>
References: <52D3A95D.9030406@geshi.org> <52DDC3DF.20606@fifthhorseman.net>
Message-ID: <52DEA4DD.8070602@geshi.org>


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Daniel,

Am 21.01.2014 01:48, schrieb Daniel Kahn Gillmor:
> On 01/13/2014 03:52 AM, Benny Baumann wrote:
>
>> Are there plans to implement OCSP stapling in mod_gnutls?
>
> I have no immediate plans for OCSP stapling in mod_gnutls (i'm still
> trying to carve out time for a proper release with some of the newer
> authentication features), but would be happy to see it added.
At least latest trunk works nicely for me; given I fetched the proper
repository ;-) (Last commit is quite a while ago, thus I'm wondering).
> For those searching for it in the codebase, OCSP stapling is known
> formally as an OCSP status request. see:
>
>   https://tools.ietf.org/html/rfc6066#section-8
Okay, good starting point for research ;-)
>> What are the places that need to be looked into to do the necessary setup?
>
> Modern versions of the GnuTLS library (since 3.1, i think) already have
> OCSP functionality, so we'd just need to hook into that in mod_gnutls.
I presumed something like that.
> The simplest minimal approach would be to add a configuration parameter
> to indicate the file to read the OCSP response from using:
>
>  gnutls_certificate_set_ocsp_status_request_file()
Will look into it; especially in the case of VHosts and multiple
certs/cert chains.
> and then rely on the server operator to update that file regularly with
> something like this (e.g. from cron or a systemd timer file):
>
> ocsptool --ask --load-cert server_cert.pem --load-issuer the_issuer.pem
>          --load-signer the_issuer.pem --outfile ocsp.response
Not a nice solution IMHO, but doable. I'd prefer an "automatic fetch"
though which would fetch the OCSP response from the OCSP server every
now and then.
>
>
> This is probably somewhat inefficient on high-traffic servers, but it
> would provide a functioning implementation, and a more complex
> in-process caching/re-fetching architecture could be built later.
>
> Would this baseline implementation be useful for you?
I think that might work for a baseline implementation. Can't tell
anything about when I might get around for it though. I'll send patches
if I have something working; otherwise assume no work done yet on this
topic.
>     --dkg
Regards,
BenBE.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQIcBAEBAgAGBQJS3qTcAAoJEPHTXLno4S6t6uoP+gL3SNiTT6v2QwXDzhnziFNo
QyG7IXgxCtj8Yv3vHNRFuPSH/aIqKssOditmBVx9c/HGp4i0fDDatCg7MqAQs7C0
yngktiCouUORMnpeSIjSlmhSYoeespsDuZQbJlpo/jAVmDKx00Yoxz6CPJR3r5Fe
bMnLD6ZhVw4vussqZInKBVcSpvdUMcg6ejmk4pfTrDprUIam6ypk5be6oDAj0FHm
7sRwbXif0iL3aq4AAhuvqVJz9uTt1FbRz9tAk8gu5I2ZIvvhzG8QmVVBp6ebwLlM
YRtJ5Z39Zs2PPnmDqB3XL2lwsEvuwqvBZsCUUKwKJ01DgHa+kIgHpta4oJvw1Aaa
/ghYSiu6NRkTh77nlHEW0JwvnDSgq4xC9axTLZqBP5rQhOmTTk6TEmoO+LHBG32F
eg/xwF2gz7SGsBkkDdPV9jHDzyv6tfaRFoIoiLZQzt8RKGxIkPKdcNKksnMGlYTu
SnqS4c9G54bTlJblbWLJKjL0y/d9B926DB7qlBMFjOwPNx2k+nDVDDjHDyroi0A6
PNVQU9Vwd102FCcHVlDEYqlMmHAqMBFMGjkIaFQYMKyt8XmDsqu/yFGReTUayXKV
yAr6DSpXJ04z77RHJUAWv5kwbhTjD15NSgtY2iuYuSSXSWxTzlhR2nNQe6EPKzpe
H6Uz2LGU1725U5sMB+sz
=iP3Q
-----END PGP SIGNATURE-----