From ramkumar.chinchani at gmail.com  Sun Mar  2 09:25:55 2014
From: ramkumar.chinchani at gmail.com (Ramkumar Chinchani)
Date: Sun, 2 Mar 2014 08:25:55 +0000
Subject: [mod_gnutls-devel] GnuTLSPGPKeyringFile?
In-Reply-To: <530EF318.2080001@geshi.org>
References: <CANCUUtDnFePMjgOUb3c7RfeZ2PGCKsbV9fQBY5Npff7cX97_Ow@mail.gmail.com>
 <530EF318.2080001@geshi.org>
Message-ID: <CANCUUtDTKVh_qqJz54mRWJuFQUL+8ZLJ49J672opxk56jS6=dg@mail.gmail.com>

Hi Benny,

Thanks for the code review.

The problem is that in the following code snippet in the function
gnutls_openpgp_keyring_import()

174       do
175         {
176           err =
177             cdk_stream_read (input, raw_data + written, raw_len -
written);
178
179           if (err > 0)
180             written += err;
181         }
182       while (written < raw_len && err != EOF && err > 0);


"err" comes with EOF in the very first iteration because of the incorrect
armor (base64 vs raw)
And this failure appears to be silent so there is no way of detecting the
failure in the caller and try a different armor.




On Thu, Feb 27, 2014 at 8:11 AM, Benny Baumann <BenBE at geshi.org> wrote:

> Hi,
>
> Am 27.02.2014 08:35, schrieb Ramkumar Chinchani:
> > Is there a way to export the entire keyring? in base64 format?
> gnupg exports all matching keys when given the --export option. Haven't
> checked though yet how to export the full keyring at once.
> >
> > If not, then I am likely pointing GnuTLSPGPKeyringFile to
> > ${HOME}/.gnupg/pubring.gpg which should be in RAW format?
> >
> >
> > diff --git a/src/gnutls_config.c b/src/gnutls_config.c
> > index 3300854..6b672f5 100644
> > --- a/src/gnutls_config.c
> > +++ b/src/gnutls_config.c
> > @@ -509,7 +509,7 @@ const char *mgs_set_keyring_file(cmd_parms *
> > parms, void *dummy,
> >      }
> >
> >      rv = gnutls_openpgp_keyring_import(sc->pgp_list, &data,
> > -            GNUTLS_OPENPGP_FMT_BASE64);
> > +            GNUTLS_OPENPGP_FMT_RAW);
> >      if (rv < 0) {
> >          return apr_psprintf(parms->pool, "GnuTLS: Failed to load "
> >                  "Keyring File '%s': (%d) %s", file, rv,
> >
> >
> I'd prefer if the old behaviour stays and it additionally allows for
> binary keyrings to be loaded. That way you won't offend existing users
> of this feature.
>
> Regards,
> BenBE.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140302/ff4bbc40/attachment-0001.html>

From ramkumar.chinchani at gmail.com  Mon Mar  3 07:03:12 2014
From: ramkumar.chinchani at gmail.com (Ramkumar Chinchani)
Date: Mon, 3 Mar 2014 06:03:12 +0000
Subject: [mod_gnutls-devel] `GnuTLSClientVerify` behavior incorrect?
In-Reply-To: <CANCUUtCG73_gJyJnTbe9fqqJwA04nDzXySNh_KdrgojqgJ5yiw@mail.gmail.com>
References: <CANCUUtCG73_gJyJnTbe9fqqJwA04nDzXySNh_KdrgojqgJ5yiw@mail.gmail.com>
Message-ID: <CANCUUtBsUYyaz30o=VjvB6M1oY8vFXTuiPKHTV7h3POQJnfD=Q@mail.gmail.com>

This is the complete patch.
Basically two changes,
1) dc->client_verify_mode = -1 unless there is a explicit directory
directive
2) msgs_cert_verify() does correctly come with HTTP_FORBIDDEN but if client
cert is "required" it must be honored


diff --git a/src/gnutls_hooks.c b/src/gnutls_hooks.c
index d068ebb..2cc8af1 100644
--- a/src/gnutls_hooks.c
+++ b/src/gnutls_hooks.c
@@ -849,7 +849,8 @@ int mgs_hook_authz(request_rec * r) {
         ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
                 "GnuTLS: Directory set to Ignore Client Certificate!");
     } else {
-        if (ctxt->sc->client_verify_mode < dc->client_verify_mode) {
+        if (dc->client_verify_mode >= 0 &&
+                ctxt->sc->client_verify_mode < dc->client_verify_mode) {
             ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
                     "GnuTLS: Attempting to rehandshake with peer. %d %d",
                     ctxt->sc->client_verify_mode,
@@ -878,7 +879,8 @@ int mgs_hook_authz(request_rec * r) {
         rv = mgs_cert_verify(r, ctxt);
         if (rv != DECLINED &&
                 (rv != HTTP_FORBIDDEN ||
-                dc->client_verify_mode == GNUTLS_CERT_REQUIRE)) {
+                dc->client_verify_mode == GNUTLS_CERT_REQUIRE ||
+                ctxt->sc->client_verify_mode == GNUTLS_CERT_REQUIRE)) {
             return rv;
         }
     }



On Tue, Feb 25, 2014 at 9:48 PM, Ramkumar Chinchani <
ramkumar.chinchani at gmail.com> wrote:

> As per current config model, it is possible that  `GnuTLSClientVerify` is
> defined in server or vhost but not under directory, in which case this is
> probably what is desired?
>
> Kindly review.
>
>
> diff --git a/src/gnutls_hooks.c b/src/gnutls_hooks.c
> index d068ebb..335ae3f 100644
> --- a/src/gnutls_hooks.c
> +++ b/src/gnutls_hooks.c
> @@ -849,7 +849,8 @@ int mgs_hook_authz(request_rec * r) {
>          ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
>                  "GnuTLS: Directory set to Ignore Client Certificate!");
>      } else {
> -        if (ctxt->sc->client_verify_mode < dc->client_verify_mode) {
> +        if (dc->client_verify_mode >= 0 &&
> +             ctxt->sc->client_verify_mode < dc->client_verify_mode) {
>              ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
>                      "GnuTLS: Attempting to rehandshake with peer. %d %d",
>                      ctxt->sc->client_verify_mode,
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140303/015a91fe/attachment.html>

From ramkumar.chinchani at gmail.com  Tue Mar  4 09:03:07 2014
From: ramkumar.chinchani at gmail.com (Ramkumar Chinchani)
Date: Tue, 4 Mar 2014 08:03:07 +0000
Subject: [mod_gnutls-devel] `GnuTLSClientVerify` behavior incorrect?
In-Reply-To: <CANCUUtBsUYyaz30o=VjvB6M1oY8vFXTuiPKHTV7h3POQJnfD=Q@mail.gmail.com>
References: <CANCUUtCG73_gJyJnTbe9fqqJwA04nDzXySNh_KdrgojqgJ5yiw@mail.gmail.com>
 <CANCUUtBsUYyaz30o=VjvB6M1oY8vFXTuiPKHTV7h3POQJnfD=Q@mail.gmail.com>
Message-ID: <CANCUUtBFuBLEKFwF6=eJ17kOS_4n9-sX4YJo43A2a+x2EdnCog@mail.gmail.com>

Next version of the patch. This is now tested and works as advertised.

The main change is in the gnutls_certificate_server_set_request() call.

void
gnutls_certificate_server_set_request (gnutls_session_t session,
                                       gnutls_certificate_request_t req)
{
  session->internals.send_cert_req = req;
}

But,

unsigned send_cert_req:1;

So this is really boolean.



diff --git a/src/gnutls_hooks.c b/src/gnutls_hooks.c
index d068ebb..ebf0a27 100644
--- a/src/gnutls_hooks.c
+++ b/src/gnutls_hooks.c
@@ -142,7 +142,7 @@ static int
mgs_select_virtual_server_cb(gnutls_session_t session) {
         ctxt->sc = tsc;
        }

-    gnutls_certificate_server_set_request(session,
ctxt->sc->client_verify_mode);
+    gnutls_certificate_server_set_request(session,
!!ctxt->sc->client_verify_mode);

     /* Set Anon credentials */
     gnutls_credentials_set(session, GNUTLS_CRD_CERTIFICATE,
ctxt->sc->certs);
@@ -849,7 +849,8 @@ int mgs_hook_authz(request_rec * r) {
         ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
                 "GnuTLS: Directory set to Ignore Client Certificate!");
     } else {
-        if (ctxt->sc->client_verify_mode < dc->client_verify_mode) {
+        if (dc->client_verify_mode >= 0 &&
+                ctxt->sc->client_verify_mode < dc->client_verify_mode) {
             ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
                     "GnuTLS: Attempting to rehandshake with peer. %d %d",
                     ctxt->sc->client_verify_mode,
@@ -862,7 +863,7 @@ int mgs_hook_authz(request_rec * r) {
                 return rv;

             gnutls_certificate_server_set_request
-                    (ctxt->session, dc->client_verify_mode);
+                    (ctxt->session, !!dc->client_verify_mode);

             if (mgs_rehandshake(ctxt) != 0) {
                 return HTTP_FORBIDDEN;
@@ -878,7 +879,8 @@ int mgs_hook_authz(request_rec * r) {
         rv = mgs_cert_verify(r, ctxt);
         if (rv != DECLINED &&
                 (rv != HTTP_FORBIDDEN ||
-                dc->client_verify_mode == GNUTLS_CERT_REQUIRE)) {
+                dc->client_verify_mode == GNUTLS_CERT_REQUIRE ||
+                ctxt->sc->client_verify_mode == GNUTLS_CERT_REQUIRE)) {
             return rv;
         }
     }



On Mon, Mar 3, 2014 at 6:03 AM, Ramkumar Chinchani <
ramkumar.chinchani at gmail.com> wrote:

> This is the complete patch.
> Basically two changes,
> 1) dc->client_verify_mode = -1 unless there is a explicit directory
> directive
> 2) msgs_cert_verify() does correctly come with HTTP_FORBIDDEN but if
> client cert is "required" it must be honored
>
>
> diff --git a/src/gnutls_hooks.c b/src/gnutls_hooks.c
> index d068ebb..2cc8af1 100644
>
> --- a/src/gnutls_hooks.c
> +++ b/src/gnutls_hooks.c
> @@ -849,7 +849,8 @@ int mgs_hook_authz(request_rec * r) {
>          ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
>                  "GnuTLS: Directory set to Ignore Client Certificate!");
>      } else {
> -        if (ctxt->sc->client_verify_mode < dc->client_verify_mode) {
> +        if (dc->client_verify_mode >= 0 &&
> +                ctxt->sc->client_verify_mode < dc->client_verify_mode) {
>              ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
>                      "GnuTLS: Attempting to rehandshake with peer. %d %d",
>                      ctxt->sc->client_verify_mode,
> @@ -878,7 +879,8 @@ int mgs_hook_authz(request_rec * r) {
>          rv = mgs_cert_verify(r, ctxt);
>          if (rv != DECLINED &&
>                  (rv != HTTP_FORBIDDEN ||
> -                dc->client_verify_mode == GNUTLS_CERT_REQUIRE)) {
> +                dc->client_verify_mode == GNUTLS_CERT_REQUIRE ||
> +                ctxt->sc->client_verify_mode == GNUTLS_CERT_REQUIRE)) {
>              return rv;
>          }
>      }
>
>
>
> On Tue, Feb 25, 2014 at 9:48 PM, Ramkumar Chinchani <
> ramkumar.chinchani at gmail.com> wrote:
>
>> As per current config model, it is possible that  `GnuTLSClientVerify` is
>> defined in server or vhost but not under directory, in which case this is
>> probably what is desired?
>>
>> Kindly review.
>>
>>
>> diff --git a/src/gnutls_hooks.c b/src/gnutls_hooks.c
>> index d068ebb..335ae3f 100644
>> --- a/src/gnutls_hooks.c
>> +++ b/src/gnutls_hooks.c
>> @@ -849,7 +849,8 @@ int mgs_hook_authz(request_rec * r) {
>>          ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
>>                  "GnuTLS: Directory set to Ignore Client Certificate!");
>>      } else {
>> -        if (ctxt->sc->client_verify_mode < dc->client_verify_mode) {
>> +        if (dc->client_verify_mode >= 0 &&
>> +             ctxt->sc->client_verify_mode < dc->client_verify_mode) {
>>              ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
>>                      "GnuTLS: Attempting to rehandshake with peer. %d %d",
>>                      ctxt->sc->client_verify_mode,
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140304/b260b2c6/attachment.html>

From ramkumar.chinchani at gmail.com  Tue Mar  4 09:14:25 2014
From: ramkumar.chinchani at gmail.com (Ramkumar Chinchani)
Date: Tue, 4 Mar 2014 08:14:25 +0000
Subject: [mod_gnutls-devel] `GnuTLSClientVerify` behavior incorrect?
In-Reply-To: <CANCUUtBFuBLEKFwF6=eJ17kOS_4n9-sX4YJo43A2a+x2EdnCog@mail.gmail.com>
References: <CANCUUtCG73_gJyJnTbe9fqqJwA04nDzXySNh_KdrgojqgJ5yiw@mail.gmail.com>
 <CANCUUtBsUYyaz30o=VjvB6M1oY8vFXTuiPKHTV7h3POQJnfD=Q@mail.gmail.com>
 <CANCUUtBFuBLEKFwF6=eJ17kOS_4n9-sX4YJo43A2a+x2EdnCog@mail.gmail.com>
Message-ID: <CANCUUtD0EHmdWbFr+PacnUJ+hZVPYnPdWHGQzrkfjr=4jqvU7Q@mail.gmail.com>

FYI.

This has been fixed in gnutls upstream

commit 4aebdbe7d424f2a1705f3751c5fef6f2e5f4e616
Author: Nikos Mavrogiannopoulos <nmav at gnutls.org>
Date:   Thu Aug 29 14:06:20 2013 +0300

    Corrected gnutls_certificate_server_set_request().

-  unsigned send_cert_req:1;
+  unsigned send_cert_req;





On Tue, Mar 4, 2014 at 8:03 AM, Ramkumar Chinchani <
ramkumar.chinchani at gmail.com> wrote:

> Next version of the patch. This is now tested and works as advertised.
>
> The main change is in the gnutls_certificate_server_set_request() call.
>
> void
> gnutls_certificate_server_set_request (gnutls_session_t session,
>                                        gnutls_certificate_request_t req)
> {
>   session->internals.send_cert_req = req;
> }
>
> But,
>
> unsigned send_cert_req:1;
>
> So this is really boolean.
>
>
>
> diff --git a/src/gnutls_hooks.c b/src/gnutls_hooks.c
> index d068ebb..ebf0a27 100644
> --- a/src/gnutls_hooks.c
> +++ b/src/gnutls_hooks.c
> @@ -142,7 +142,7 @@ static int
> mgs_select_virtual_server_cb(gnutls_session_t session) {
>          ctxt->sc = tsc;
>         }
>
> -    gnutls_certificate_server_set_request(session,
> ctxt->sc->client_verify_mode);
> +    gnutls_certificate_server_set_request(session,
> !!ctxt->sc->client_verify_mode);
>
>      /* Set Anon credentials */
>      gnutls_credentials_set(session, GNUTLS_CRD_CERTIFICATE,
> ctxt->sc->certs);
>
> @@ -849,7 +849,8 @@ int mgs_hook_authz(request_rec * r) {
>          ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
>                  "GnuTLS: Directory set to Ignore Client Certificate!");
>      } else {
> -        if (ctxt->sc->client_verify_mode < dc->client_verify_mode) {
> +        if (dc->client_verify_mode >= 0 &&
> +                ctxt->sc->client_verify_mode < dc->client_verify_mode) {
>              ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
>                      "GnuTLS: Attempting to rehandshake with peer. %d %d",
>                      ctxt->sc->client_verify_mode,
> @@ -862,7 +863,7 @@ int mgs_hook_authz(request_rec * r) {
>                  return rv;
>
>              gnutls_certificate_server_set_request
> -                    (ctxt->session, dc->client_verify_mode);
> +                    (ctxt->session, !!dc->client_verify_mode);
>
>              if (mgs_rehandshake(ctxt) != 0) {
>                  return HTTP_FORBIDDEN;
>
> @@ -878,7 +879,8 @@ int mgs_hook_authz(request_rec * r) {
>          rv = mgs_cert_verify(r, ctxt);
>          if (rv != DECLINED &&
>                  (rv != HTTP_FORBIDDEN ||
> -                dc->client_verify_mode == GNUTLS_CERT_REQUIRE)) {
> +                dc->client_verify_mode == GNUTLS_CERT_REQUIRE ||
> +                ctxt->sc->client_verify_mode == GNUTLS_CERT_REQUIRE)) {
>              return rv;
>          }
>      }
>
>
>
> On Mon, Mar 3, 2014 at 6:03 AM, Ramkumar Chinchani <
> ramkumar.chinchani at gmail.com> wrote:
>
>> This is the complete patch.
>> Basically two changes,
>> 1) dc->client_verify_mode = -1 unless there is a explicit directory
>> directive
>> 2) msgs_cert_verify() does correctly come with HTTP_FORBIDDEN but if
>> client cert is "required" it must be honored
>>
>>
>> diff --git a/src/gnutls_hooks.c b/src/gnutls_hooks.c
>> index d068ebb..2cc8af1 100644
>>
>> --- a/src/gnutls_hooks.c
>> +++ b/src/gnutls_hooks.c
>> @@ -849,7 +849,8 @@ int mgs_hook_authz(request_rec * r) {
>>          ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
>>                  "GnuTLS: Directory set to Ignore Client Certificate!");
>>      } else {
>> -        if (ctxt->sc->client_verify_mode < dc->client_verify_mode) {
>> +        if (dc->client_verify_mode >= 0 &&
>> +                ctxt->sc->client_verify_mode < dc->client_verify_mode) {
>>              ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
>>                      "GnuTLS: Attempting to rehandshake with peer. %d %d",
>>                      ctxt->sc->client_verify_mode,
>> @@ -878,7 +879,8 @@ int mgs_hook_authz(request_rec * r) {
>>          rv = mgs_cert_verify(r, ctxt);
>>          if (rv != DECLINED &&
>>                  (rv != HTTP_FORBIDDEN ||
>> -                dc->client_verify_mode == GNUTLS_CERT_REQUIRE)) {
>> +                dc->client_verify_mode == GNUTLS_CERT_REQUIRE ||
>> +                ctxt->sc->client_verify_mode == GNUTLS_CERT_REQUIRE)) {
>>              return rv;
>>          }
>>      }
>>
>>
>>
>> On Tue, Feb 25, 2014 at 9:48 PM, Ramkumar Chinchani <
>> ramkumar.chinchani at gmail.com> wrote:
>>
>>> As per current config model, it is possible that  `GnuTLSClientVerify`
>>> is defined in server or vhost but not under directory, in which case this
>>> is probably what is desired?
>>>
>>> Kindly review.
>>>
>>>
>>> diff --git a/src/gnutls_hooks.c b/src/gnutls_hooks.c
>>> index d068ebb..335ae3f 100644
>>> --- a/src/gnutls_hooks.c
>>> +++ b/src/gnutls_hooks.c
>>> @@ -849,7 +849,8 @@ int mgs_hook_authz(request_rec * r) {
>>>          ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
>>>                  "GnuTLS: Directory set to Ignore Client Certificate!");
>>>      } else {
>>> -        if (ctxt->sc->client_verify_mode < dc->client_verify_mode) {
>>> +        if (dc->client_verify_mode >= 0 &&
>>> +             ctxt->sc->client_verify_mode < dc->client_verify_mode) {
>>>              ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
>>>                      "GnuTLS: Attempting to rehandshake with peer. %d
>>> %d",
>>>                      ctxt->sc->client_verify_mode,
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140304/d7a0ee8f/attachment-0001.html>

From dkg at fifthhorseman.net  Tue Mar  4 11:35:14 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 04 Mar 2014 10:35:14 +0000
Subject: [mod_gnutls-devel] [gnutls-help] Ubuntu 12.04lts Apache 2.4
	mod_gnutls.so
In-Reply-To: <00c101cf370e$81be5cc0$853b1640$@com>
References: <00c101cf370e$81be5cc0$853b1640$@com>
Message-ID: <5315AC62.2020602@fifthhorseman.net>

Hi Frank--

On 03/03/2014 06:29 PM, Frank J Polan wrote:
> This is my first posting to this list. If I'm doing anything wrong or
> breaking any rules please let me know
> The following describes the problem ( as I posted to another forum)
> 
> Ubuntu 12.04LTS Apache 2.4 I've installed TLS be following the steps on this
> link https://help.ubuntu.com/community/GnuTLS
> When restarting Apache I get the following error
> apache2: Syntax error on line 212 of /etc/apache2/apache2.conf: Syntax error
> on line 1 of /etc/apache2/mods-enabled/gnutls.load: Cannot load
> /usr/lib/apache2/modules/mod_gnutls.so into server:
> /usr/lib/apache2/modules/mod_gnutls.so: undefined symbol: unixd_config
> 
> If I remove the @gnutls.conf file from the /etc/apache2/mods-enabled
> directory Apache restarts
> Any suggestions would be appreciated
> Thanks
> Frank
> 
> It's been suggested that the GnuTLS package in 12.04LTS hasn't been updated
> for apache 2.4 If that's the case is there a repository with an updated
> version or should I revert to apache2.2 

it sounds like you're running into a problem with apache mod_gnutls,
which is a distinct project from gnutls itself -- mod_gnutls is a
project to connect Apache (the web server) with the GnuTLS transport
layer security library.

The right place to follow up on this is probably either the mod_gnutls
mailing list (i'm cc'ing it here):

  mod_gnutls-devel at lists.gnutls.org

or on ubuntu's packaging bug reports on https://launchpad.net/

fwiw, the mod_gnutls packaging for ubuntu should have caught this error
message during the test suite.

however, looking at http://packages.ubuntu.com/search?keywords=apache2,
i don't think that ubuntu 12.04 LTS actually has apache 2.4 at all (i
think it shipped with apache 2.2), so i'm not sure what is going on with
your system.

Did you compile these tools yourself?  if so, what versions are you
working with?

Regards,

	--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/20140304/8bb58965/attachment.sig>

From fpolan at rogers.com  Tue Mar  4 15:30:29 2014
From: fpolan at rogers.com (Frank J Polan)
Date: Tue, 4 Mar 2014 09:30:29 -0500
Subject: [mod_gnutls-devel] [gnutls-help] Ubuntu 12.04lts Apache 2.4
	mod_gnutls.so
In-Reply-To: <5315AC62.2020602@fifthhorseman.net>
References: <00c101cf370e$81be5cc0$853b1640$@com>
 <5315AC62.2020602@fifthhorseman.net>
Message-ID: <00d001cf37b6$4b5ee700$e21cb500$@com>

Daniel

Thanks for the excellent explanation. You're correct 12.04lts doesn't have apache2.4; I downloaded it from a different repository. I'll uninstall it and revert back to 2.2 until it's an official Ubuntu release

Thanks

Frank Polan


-----Original Message-----
From: Daniel Kahn Gillmor [mailto:dkg at fifthhorseman.net] 
Sent: March-04-2014 05:35
To: Frank J Polan; gnutls-help at lists.gnutls.org; mod_gnutls-devel at lists.gnutls.org
Subject: Re: [gnutls-help] Ubuntu 12.04lts Apache 2.4 mod_gnutls.so

Hi Frank--

On 03/03/2014 06:29 PM, Frank J Polan wrote:
> This is my first posting to this list. If I'm doing anything wrong or 
> breaking any rules please let me know The following describes the 
> problem ( as I posted to another forum)
> 
> Ubuntu 12.04LTS Apache 2.4 I've installed TLS be following the steps 
> on this link https://help.ubuntu.com/community/GnuTLS
> When restarting Apache I get the following error
> apache2: Syntax error on line 212 of /etc/apache2/apache2.conf: Syntax 
> error on line 1 of /etc/apache2/mods-enabled/gnutls.load: Cannot load 
> /usr/lib/apache2/modules/mod_gnutls.so into server:
> /usr/lib/apache2/modules/mod_gnutls.so: undefined symbol: unixd_config
> 
> If I remove the @gnutls.conf file from the /etc/apache2/mods-enabled 
> directory Apache restarts Any suggestions would be appreciated Thanks 
> Frank
> 
> It's been suggested that the GnuTLS package in 12.04LTS hasn't been 
> updated for apache 2.4 If that's the case is there a repository with 
> an updated version or should I revert to apache2.2

it sounds like you're running into a problem with apache mod_gnutls, which is a distinct project from gnutls itself -- mod_gnutls is a project to connect Apache (the web server) with the GnuTLS transport layer security library.

The right place to follow up on this is probably either the mod_gnutls mailing list (i'm cc'ing it here):

  mod_gnutls-devel at lists.gnutls.org

or on ubuntu's packaging bug reports on https://launchpad.net/

fwiw, the mod_gnutls packaging for ubuntu should have caught this error message during the test suite.

however, looking at http://packages.ubuntu.com/search?keywords=apache2,
i don't think that ubuntu 12.04 LTS actually has apache 2.4 at all (i think it shipped with apache 2.2), so i'm not sure what is going on with your system.

Did you compile these tools yourself?  if so, what versions are you working with?

Regards,

	--dkg




From ramkumar.chinchani at gmail.com  Fri Mar  7 08:34:24 2014
From: ramkumar.chinchani at gmail.com (Ramkumar Chinchani)
Date: Fri, 7 Mar 2014 07:34:24 +0000
Subject: [mod_gnutls-devel] GnuTLSPGPKeyringFile?
In-Reply-To: <CANCUUtDTKVh_qqJz54mRWJuFQUL+8ZLJ49J672opxk56jS6=dg@mail.gmail.com>
References: <CANCUUtDnFePMjgOUb3c7RfeZ2PGCKsbV9fQBY5Npff7cX97_Ow@mail.gmail.com>
 <530EF318.2080001@geshi.org>
 <CANCUUtDTKVh_qqJz54mRWJuFQUL+8ZLJ49J672opxk56jS6=dg@mail.gmail.com>
Message-ID: <CANCUUtAmDrK18CeiuuA8Pf9TVvruDnxxOyAD1LqUE=wQM6VK7Q@mail.gmail.com>

FYI.

Suggested a patch upstream [1] which should make this happen.

[1] http://lists.gnutls.org/pipermail/gnutls-devel/2014-March/006803.html



On Sun, Mar 2, 2014 at 8:25 AM, Ramkumar Chinchani <
ramkumar.chinchani at gmail.com> wrote:

> Hi Benny,
>
> Thanks for the code review.
>
> The problem is that in the following code snippet in the function
> gnutls_openpgp_keyring_import()
>
> 174       do
> 175         {
> 176           err =
> 177             cdk_stream_read (input, raw_data + written, raw_len -
> written);
> 178
> 179           if (err > 0)
> 180             written += err;
> 181         }
> 182       while (written < raw_len && err != EOF && err > 0);
>
>
> "err" comes with EOF in the very first iteration because of the incorrect
> armor (base64 vs raw)
> And this failure appears to be silent so there is no way of detecting the
> failure in the caller and try a different armor.
>
>
>
>
> On Thu, Feb 27, 2014 at 8:11 AM, Benny Baumann <BenBE at geshi.org> wrote:
>
>> Hi,
>>
>> Am 27.02.2014 08:35, schrieb Ramkumar Chinchani:
>> > Is there a way to export the entire keyring? in base64 format?
>> gnupg exports all matching keys when given the --export option. Haven't
>> checked though yet how to export the full keyring at once.
>> >
>> > If not, then I am likely pointing GnuTLSPGPKeyringFile to
>> > ${HOME}/.gnupg/pubring.gpg which should be in RAW format?
>> >
>> >
>> > diff --git a/src/gnutls_config.c b/src/gnutls_config.c
>> > index 3300854..6b672f5 100644
>> > --- a/src/gnutls_config.c
>> > +++ b/src/gnutls_config.c
>> > @@ -509,7 +509,7 @@ const char *mgs_set_keyring_file(cmd_parms *
>> > parms, void *dummy,
>> >      }
>> >
>> >      rv = gnutls_openpgp_keyring_import(sc->pgp_list, &data,
>> > -            GNUTLS_OPENPGP_FMT_BASE64);
>> > +            GNUTLS_OPENPGP_FMT_RAW);
>> >      if (rv < 0) {
>> >          return apr_psprintf(parms->pool, "GnuTLS: Failed to load "
>> >                  "Keyring File '%s': (%d) %s", file, rv,
>> >
>> >
>> I'd prefer if the old behaviour stays and it additionally allows for
>> binary keyrings to be loaded. That way you won't offend existing users
>> of this feature.
>>
>> Regards,
>> BenBE.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140307/40e5280e/attachment.html>

From ramkumar.chinchani at gmail.com  Wed Mar 12 05:35:26 2014
From: ramkumar.chinchani at gmail.com (Ramkumar Chinchani)
Date: Tue, 11 Mar 2014 21:35:26 -0700
Subject: [mod_gnutls-devel] msva validation error handling
Message-ID: <CANCUUtBjW6nNTR9DFtzmkLAZz7SBL05TJbYY5XyS2hnpDunvpQ@mail.gmail.com>

In mgs_cert_verify() when using the msva validation path, there is a free()
of unallocated memory when the connection to the msva validation agent
fails.

Kindly be advised of a possible patch [1] to libmsv [2]

[1]
https://gitorious.org/libmsv/libmsv/commit/0915099e639fee8f90737ecb217931f07b4e6f7c
[2] http://anonscm.debian.org/gitweb/?p=users/clint/libmsv.git
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140311/6f617e26/attachment.html>

From ramkumar.chinchani at gmail.com  Wed Mar 12 05:37:48 2014
From: ramkumar.chinchani at gmail.com (Ramkumar Chinchani)
Date: Tue, 11 Mar 2014 21:37:48 -0700
Subject: [mod_gnutls-devel] how to pass/set
	MONKEYSPHERE_VALIDATION_AGENT_SOCKET for msva validation?
Message-ID: <CANCUUtCq5+o075KRh=BkiUuCTsNQpVWRB=k+3+9of+FfSBey4w@mail.gmail.com>

Setting the environment variable via the SetEnv approach [1] doesn't seem
to work.

Suggestions?

[1] http://httpd.apache.org/docs/current/env.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140311/581111a1/attachment-0001.html>

From dkg at fifthhorseman.net  Wed Mar 12 15:13:08 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 12 Mar 2014 10:13:08 -0400
Subject: [mod_gnutls-devel] how to pass/set
 MONKEYSPHERE_VALIDATION_AGENT_SOCKET for msva validation?
In-Reply-To: <CANCUUtCq5+o075KRh=BkiUuCTsNQpVWRB=k+3+9of+FfSBey4w@mail.gmail.com>
References: <CANCUUtCq5+o075KRh=BkiUuCTsNQpVWRB=k+3+9of+FfSBey4w@mail.gmail.com>
Message-ID: <53206B74.2080707@fifthhorseman.net>

Hi Ramkumar--

On 03/12/2014 12:37 AM, Ramkumar Chinchani wrote:
> Setting the environment variable via the SetEnv approach [1] doesn't seem
> to work.
> 
> Suggestions?
> 
> [1] http://httpd.apache.org/docs/current/env.html

SetEnv is used to change the environment variable for child processes or
for apache configuration directives (see the first section of the page
you linked above).

On a debian system using sysvinit to start apache, there is a config
file /etc/apache2/envvars where you can add a line like:

 export MONKEYSPHERE_VALIDATION_AGENT_SOCKET=http://127.0.0.1:9999/

If you're using other initialization systems, i'm sure there are other
ways you can set the environment variable for the daemon process (e.g.
see the Environment= directive in systemd.exec(5) if you use systemd)

hope this helps,

	--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/20140312/cdd35bb0/attachment.sig>

From dkg at fifthhorseman.net  Wed Mar 12 20:03:07 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 12 Mar 2014 15:03:07 -0400
Subject: [mod_gnutls-devel] msva validation error handling
In-Reply-To: <CANCUUtBjW6nNTR9DFtzmkLAZz7SBL05TJbYY5XyS2hnpDunvpQ@mail.gmail.com>
References: <CANCUUtBjW6nNTR9DFtzmkLAZz7SBL05TJbYY5XyS2hnpDunvpQ@mail.gmail.com>
Message-ID: <87vbvjs0ic.fsf@alice.fifthhorseman.net>

Hi Ramkumar--

On Wed 2014-03-12 00:35:26 -0400, Ramkumar Chinchani wrote:
> In mgs_cert_verify() when using the msva validation path, there is a free()
> of unallocated memory when the connection to the msva validation agent
> fails.

Thanks for noticing this!

> Kindly be advised of a possible patch [1] to libmsv [2]
>
> [1] https://gitorious.org/libmsv/libmsv/commit/0915099e639fee8f90737ecb217931f07b4e6f7c
> [2] http://anonscm.debian.org/gitweb/?p=users/clint/libmsv.git

It's easier to comment on a  patch when it's in the e-mail, so i'm including it here:

-----------------
--- a/msv.c
+++ b/msv.c
@@ -231,7 +231,7 @@
   pkc = json_object ();
   peer = json_object ();
 
-  response = malloc (sizeof (struct msv_response));
+  response = calloc (1, sizeof (struct msv_response));
   *response_ptr = response;
 
   if ((j_pkcdata = json_string (q.pkcdata)) &&

--------------

The concern here is that we want to ensure the message member of the
response object is NULL, right?

i agree that the fix belongs in libmsv.  i also note that libmsv doesn't
gracefully handle an out-of-memory condition here either, though.  the
following patch to libmsv should handle these cases more robustly.

Clint, what do you think?

       --dkg

commit 425528fb2324ed3bbf105d58e029d9fe35d497ae
Author: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
Date:   Wed Mar 12 15:00:41 2014 -0400

    handle out of memory errors more gracefully

diff --git a/msv.c b/msv.c
index bea92f4..858a31c 100644
--- a/msv.c
+++ b/msv.c
@@ -231,9 +231,6 @@ msv_query_agent (msv_ctxt_t ctx, struct msv_query q,
   pkc = json_object ();
   peer = json_object ();
 
-  response = malloc (sizeof (struct msv_response));
-  *response_ptr = response;
-
   if ((j_pkcdata = json_string (q.pkcdata)) &&
       (j_pkctype = json_string (q.pkctype)) &&
       (j_peername = json_string (q.peername)) &&
@@ -346,6 +343,15 @@ msv_query_agent (msv_ctxt_t ctx, struct msv_query q,
       return LIBMSV_ERROR_CURLCODE;
     }
 
+  if (! (response = malloc (sizeof (struct msv_response)))) {
+    curl_easy_cleanup (c);
+    free (req);
+    curl_slist_free_all (slist);
+    return LIBMSV_ERROR_NOMEM;
+  }
+  response->message = NULL;
+  *response_ptr = response;
+
   j = json_loads (buf, 0, &je);
   free (buf);
 
@@ -366,6 +372,14 @@ msv_query_agent (msv_ctxt_t ctx, struct msv_query q,
   curl_easy_cleanup (c);
   free (req);
 
+  if (!response->message) {
+    /* strdup returned NULL, which suggests a memory allocation
+       failure */
+    msv_response_destroy(response);
+    *response_ptr = NULL;
+    return LIBMSV_ERROR_NOMEM;
+  }
+
   return !(response->valid);
 }
 
diff --git a/msv/msv.h b/msv/msv.h
index 2080043..622037d 100644
--- a/msv/msv.h
+++ b/msv/msv.h
@@ -51,6 +51,12 @@
 #define LIBMSV_ERROR_UNEXPECTED_RESPONSE 7
 
 /**
+ * @def LIBMSV_ERROR_NOMEM
+ * @brief necessary memory allocation failed
+ */
+#define LIBMSV_ERROR_NOMEM 8
+
+/**
  * @typedef msv_ctxt_t
  * @brief opaque MSVA context
  */
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20140312/6415dd96/attachment.sig>

From dkg at fifthhorseman.net  Thu Mar 13 04:32:50 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 12 Mar 2014 23:32:50 -0400
Subject: [mod_gnutls-devel] msva validation error handling
In-Reply-To: <20140313030536.GA1122@scru.org>
References: <CANCUUtBjW6nNTR9DFtzmkLAZz7SBL05TJbYY5XyS2hnpDunvpQ@mail.gmail.com>
 <87vbvjs0ic.fsf@alice.fifthhorseman.net> <20140313030536.GA1122@scru.org>
Message-ID: <532126E2.8080703@fifthhorseman.net>

On 03/12/2014 11:05 PM, Clint Adams wrote:
> On Wed, Mar 12, 2014 at 03:03:07PM -0400, Daniel Kahn Gillmor wrote:
>> Clint, what do you think?
> 
> The fixes seem good.
> 
> The calloc fix is setting `sz' to 0.  Your patch is not.
> This leads me to wonder why `sz' was added in the first place
> and why it's not being used in any way.

i agree, sz is puzzling.  perhaps it should be removed?  This is
technically an ABI change, i think, but i don't know that it necessarily
matters.

	--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/20140312/df5444bc/attachment.sig>

From clint at debian.org  Thu Mar 13 04:05:36 2014
From: clint at debian.org (Clint Adams)
Date: Thu, 13 Mar 2014 03:05:36 +0000
Subject: [mod_gnutls-devel] msva validation error handling
In-Reply-To: <87vbvjs0ic.fsf@alice.fifthhorseman.net>
References: <CANCUUtBjW6nNTR9DFtzmkLAZz7SBL05TJbYY5XyS2hnpDunvpQ@mail.gmail.com>
 <87vbvjs0ic.fsf@alice.fifthhorseman.net>
Message-ID: <20140313030536.GA1122@scru.org>

On Wed, Mar 12, 2014 at 03:03:07PM -0400, Daniel Kahn Gillmor wrote:
> Clint, what do you think?

The fixes seem good.

The calloc fix is setting `sz' to 0.  Your patch is not.
This leads me to wonder why `sz' was added in the first place
and why it's not being used in any way.


From clint at debian.org  Thu Mar 13 04:42:23 2014
From: clint at debian.org (Clint Adams)
Date: Thu, 13 Mar 2014 03:42:23 +0000
Subject: [mod_gnutls-devel] msva validation error handling
In-Reply-To: <532126E2.8080703@fifthhorseman.net>
References: <CANCUUtBjW6nNTR9DFtzmkLAZz7SBL05TJbYY5XyS2hnpDunvpQ@mail.gmail.com>
 <87vbvjs0ic.fsf@alice.fifthhorseman.net>
 <20140313030536.GA1122@scru.org>
 <532126E2.8080703@fifthhorseman.net>
Message-ID: <20140313034223.GA4379@scru.org>

On Wed, Mar 12, 2014 at 11:32:50PM -0400, Daniel Kahn Gillmor wrote:
> i agree, sz is puzzling.  perhaps it should be removed?  This is
> technically an ABI change, i think, but i don't know that it necessarily
> matters.

I guess I'll mark it deprecated and queue it up for removal at the next
ABI break unless someone comes up with a purpose.


From ramkumar.chinchani at gmail.com  Thu Mar 13 22:01:00 2014
From: ramkumar.chinchani at gmail.com (Ramkumar Chinchani)
Date: Thu, 13 Mar 2014 14:01:00 -0700
Subject: [mod_gnutls-devel] msv_ctxt_init() cleanup
Message-ID: <CANCUUtA_KTmdHRq3iNO+RZ1-izBSNgPesnRtXTDKmX49C=HMHQ@mail.gmail.com>

This is a libmsv patch again. Sorry, couldn't find a better place to post
this.

Consequently, mod_gnutls code has to handle this error case now.

Also noticed that msv.c has a few more malloc's and strdup's without proper
out-of-memory handling.


diff --git a/msv.c b/msv.c
index b56b3a6..8ed4837 100644
--- a/msv.c
+++ b/msv.c
@@ -78,16 +78,28 @@ msv_ctxt_init (const char *url)
 {

   msv_ctxt_t ctx;
+  char *env;

   ctx = malloc (sizeof (struct msv_ctxt));
+  if (!ctx)
+    return NULL;

   if (url)
     ctx->socket_location = strdup (url);
-  else
+  else if ((env = getenv ("MONKEYSPHERE_VALIDATION_AGENT_SOCKET")))
+    ctx->socket_location = strdup (env);
+  else
+    {
+      free(ctx);
+      return NULL;
+    }
+
+  if (!ctx->socket_location)
     {
-      ctx->socket_location =
-       strdup (getenv ("MONKEYSPHERE_VALIDATION_AGENT_SOCKET"));
+      free(ctx);
+      return NULL;
     }
+
   return ctx;
 }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140313/a7e0138b/attachment.html>

From clint at debian.org  Fri Mar 14 02:23:58 2014
From: clint at debian.org (Clint Adams)
Date: Fri, 14 Mar 2014 01:23:58 +0000
Subject: [mod_gnutls-devel] msv_ctxt_init() cleanup
In-Reply-To: <CANCUUtA_KTmdHRq3iNO+RZ1-izBSNgPesnRtXTDKmX49C=HMHQ@mail.gmail.com>
References: <CANCUUtA_KTmdHRq3iNO+RZ1-izBSNgPesnRtXTDKmX49C=HMHQ@mail.gmail.com>
Message-ID: <20140314012358.GA28600@scru.org>

On Thu, Mar 13, 2014 at 02:01:00PM -0700, Ramkumar Chinchani wrote:
> Also noticed that msv.c has a few more malloc's and strdup's without proper
> out-of-memory handling.

Thanks, pushed with whitespace changes.


From ramkumar.chinchani at gmail.com  Fri Mar 14 07:58:20 2014
From: ramkumar.chinchani at gmail.com (Ramkumar Chinchani)
Date: Thu, 13 Mar 2014 23:58:20 -0700
Subject: [mod_gnutls-devel] mgs_hook_authz() handling of return values from
	mgs_cert_verify()?
Message-ID: <CANCUUtD+Lbb2RY2=txNs+Dx--_JrzCBatxz4OjArRLG_q_5_nQ@mail.gmail.com>

When GnuTLSClientVerify method is set to cartel or msva, mgs_cert_verify()
correctly returns HTTP_FORBIDDEN when verification fails.

However, when GnuTLSClientVerify is set to "require" at server-level and
not at directory-level, mgs_hook_authz() doesn't seem to honor the return
code properly for this case.

Kindly review the following patch.

diff --git a/src/gnutls_hooks.c b/src/gnutls_hooks.c
index d068ebb..5bfc2b6 100644
--- a/src/gnutls_hooks.c
+++ b/src/gnutls_hooks.c
@@ -878,7 +878,8 @@ int mgs_hook_authz(request_rec * r) {
         rv = mgs_cert_verify(r, ctxt);
         if (rv != DECLINED &&
                 (rv != HTTP_FORBIDDEN ||
-                dc->client_verify_mode == GNUTLS_CERT_REQUIRE)) {
+                dc->client_verify_mode == GNUTLS_CERT_REQUIRE ||
+                ctxt->sc->client_verify_mode == GNUTLS_CERT_REQUIRE)) {
             return rv;
         }
     }
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140313/849147d6/attachment.html>

From ramkumar.chinchani at gmail.com  Fri Mar 14 08:04:14 2014
From: ramkumar.chinchani at gmail.com (Ramkumar Chinchani)
Date: Fri, 14 Mar 2014 00:04:14 -0700
Subject: [mod_gnutls-devel] GnuTLSPGPKeyringFile?
In-Reply-To: <CANCUUtAmDrK18CeiuuA8Pf9TVvruDnxxOyAD1LqUE=wQM6VK7Q@mail.gmail.com>
References: <CANCUUtDnFePMjgOUb3c7RfeZ2PGCKsbV9fQBY5Npff7cX97_Ow@mail.gmail.com>
 <530EF318.2080001@geshi.org>
 <CANCUUtDTKVh_qqJz54mRWJuFQUL+8ZLJ49J672opxk56jS6=dg@mail.gmail.com>
 <CANCUUtAmDrK18CeiuuA8Pf9TVvruDnxxOyAD1LqUE=wQM6VK7Q@mail.gmail.com>
Message-ID: <CANCUUtAgVBy4dkEpUxaUsaZ+D_kDSVEd1dOmfWuUtnaVPOBAPg@mail.gmail.com>

mod_gnutls-side fix.

This can be consumed now but won't really be effective until some next
gnutls stable release containing the silent failure fix.


diff --git a/src/gnutls_config.c b/src/gnutls_config.c
index 3300854..8bae9ec 100644
--- a/src/gnutls_config.c
+++ b/src/gnutls_config.c
@@ -508,12 +508,18 @@ const char *mgs_set_keyring_file(cmd_parms * parms,
void *dummy,
                 gnutls_strerror(rv));
     }

+    /* first attempt loading in base64 format */
     rv = gnutls_openpgp_keyring_import(sc->pgp_list, &data,
             GNUTLS_OPENPGP_FMT_BASE64);
     if (rv < 0) {
-        return apr_psprintf(parms->pool, "GnuTLS: Failed to load "
-                "Keyring File '%s': (%d) %s", file, rv,
-                gnutls_strerror(rv));
+        /* next try raw format */
+        rv = gnutls_openpgp_keyring_import(sc->pgp_list, &data,
+                GNUTLS_OPENPGP_FMT_RAW);
+        if (rv < 0) {
+            return apr_psprintf(parms->pool, "GnuTLS: Failed to load "
+                    "Keyring File '%s': (%d) %s", file, rv,
+                    gnutls_strerror(rv));
+        }
     }

     apr_pool_destroy(spool);



On Thu, Mar 6, 2014 at 11:34 PM, Ramkumar Chinchani <
ramkumar.chinchani at gmail.com> wrote:

> FYI.
>
> Suggested a patch upstream [1] which should make this happen.
>
> [1] http://lists.gnutls.org/pipermail/gnutls-devel/2014-March/006803.html
>
>
>
> On Sun, Mar 2, 2014 at 8:25 AM, Ramkumar Chinchani <
> ramkumar.chinchani at gmail.com> wrote:
>
>> Hi Benny,
>>
>> Thanks for the code review.
>>
>> The problem is that in the following code snippet in the function
>> gnutls_openpgp_keyring_import()
>>
>> 174       do
>> 175         {
>> 176           err =
>> 177             cdk_stream_read (input, raw_data + written, raw_len -
>> written);
>> 178
>> 179           if (err > 0)
>> 180             written += err;
>> 181         }
>> 182       while (written < raw_len && err != EOF && err > 0);
>>
>>
>> "err" comes with EOF in the very first iteration because of the incorrect
>> armor (base64 vs raw)
>> And this failure appears to be silent so there is no way of detecting the
>> failure in the caller and try a different armor.
>>
>>
>>
>>
>> On Thu, Feb 27, 2014 at 8:11 AM, Benny Baumann <BenBE at geshi.org> wrote:
>>
>>> Hi,
>>>
>>> Am 27.02.2014 08:35, schrieb Ramkumar Chinchani:
>>> > Is there a way to export the entire keyring? in base64 format?
>>> gnupg exports all matching keys when given the --export option. Haven't
>>> checked though yet how to export the full keyring at once.
>>> >
>>> > If not, then I am likely pointing GnuTLSPGPKeyringFile to
>>> > ${HOME}/.gnupg/pubring.gpg which should be in RAW format?
>>> >
>>> >
>>> > diff --git a/src/gnutls_config.c b/src/gnutls_config.c
>>> > index 3300854..6b672f5 100644
>>> > --- a/src/gnutls_config.c
>>> > +++ b/src/gnutls_config.c
>>> > @@ -509,7 +509,7 @@ const char *mgs_set_keyring_file(cmd_parms *
>>> > parms, void *dummy,
>>> >      }
>>> >
>>> >      rv = gnutls_openpgp_keyring_import(sc->pgp_list, &data,
>>> > -            GNUTLS_OPENPGP_FMT_BASE64);
>>> > +            GNUTLS_OPENPGP_FMT_RAW);
>>> >      if (rv < 0) {
>>> >          return apr_psprintf(parms->pool, "GnuTLS: Failed to load "
>>> >                  "Keyring File '%s': (%d) %s", file, rv,
>>> >
>>> >
>>> I'd prefer if the old behaviour stays and it additionally allows for
>>> binary keyrings to be loaded. That way you won't offend existing users
>>> of this feature.
>>>
>>> Regards,
>>> BenBE.
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140314/bc01400d/attachment.html>

From dkg at fifthhorseman.net  Fri Mar 14 22:28:34 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 14 Mar 2014 17:28:34 -0400
Subject: [mod_gnutls-devel] mgs_hook_authz() handling of return values
 from mgs_cert_verify()?
In-Reply-To: <CANCUUtD+Lbb2RY2=txNs+Dx--_JrzCBatxz4OjArRLG_q_5_nQ@mail.gmail.com>
References: <CANCUUtD+Lbb2RY2=txNs+Dx--_JrzCBatxz4OjArRLG_q_5_nQ@mail.gmail.com>
Message-ID: <53237482.8060105@fifthhorseman.net>

On 03/14/2014 02:58 AM, Ramkumar Chinchani wrote:
> When GnuTLSClientVerify method is set to cartel or msva, mgs_cert_verify()
> correctly returns HTTP_FORBIDDEN when verification fails.
> 
> However, when GnuTLSClientVerify is set to "require" at server-level and
> not at directory-level, mgs_hook_authz() doesn't seem to honor the return
> code properly for this case.
> 
> Kindly review the following patch.
> 
> diff --git a/src/gnutls_hooks.c b/src/gnutls_hooks.c
> index d068ebb..5bfc2b6 100644
> --- a/src/gnutls_hooks.c
> +++ b/src/gnutls_hooks.c
> @@ -878,7 +878,8 @@ int mgs_hook_authz(request_rec * r) {
>          rv = mgs_cert_verify(r, ctxt);
>          if (rv != DECLINED &&
>                  (rv != HTTP_FORBIDDEN ||
> -                dc->client_verify_mode == GNUTLS_CERT_REQUIRE)) {
> +                dc->client_verify_mode == GNUTLS_CERT_REQUIRE ||
> +                ctxt->sc->client_verify_mode == GNUTLS_CERT_REQUIRE)) {
>              return rv;
>          }
>      }


Thanks, Ramkumar!  it sounds like you've got a couple test cases in mind
for this.  can you add new test cases to avoid this kind of breakage in
the future?  It seems funny to introduce two test cases to verify a
3-line patch, but they should help us avoid seeing this problem crop up
again in the future.

	--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/20140314/c9080790/attachment.sig>

From ramkumar.chinchani at gmail.com  Tue Mar 18 22:09:41 2014
From: ramkumar.chinchani at gmail.com (Ramkumar Chinchani)
Date: Tue, 18 Mar 2014 14:09:41 -0700
Subject: [mod_gnutls-devel] msv_ctxt_init() cleanup
In-Reply-To: <20140314012358.GA28600@scru.org>
References: <CANCUUtA_KTmdHRq3iNO+RZ1-izBSNgPesnRtXTDKmX49C=HMHQ@mail.gmail.com>
 <20140314012358.GA28600@scru.org>
Message-ID: <CANCUUtDLzyUAb7Z0ufXP=VMgBwYLWZ-Epj=tBOsSVKDmFSpb_w@mail.gmail.com>

Test code cleanup after recent code changes.

diff --git a/checkmsva.c b/checkmsva.c
index 1c64977..aaa3133 100644
--- a/checkmsva.c
+++ b/checkmsva.c
@@ -17,6 +17,7 @@

 #include <stdlib.h>
 #include <stdio.h>
+#include <signal.h>

 #include "msv/msv.h"

@@ -29,6 +30,12 @@ main (int argc, char **argv)
   struct msv_response *response;

   ctx = msv_ctxt_init (NULL);
+  if (!ctx) {
+      printf ("Unable to initialize context\n"
+              "Make sure MONKEYSPHERE_VALIDATION_AGENT_SOCKET env variable
is set and\n"
+              "the MSVA validation agent is running\n");
+      exit (1);
+  }

   x = msv_check_msva (ctx);
   printf ("MSVA check: %s\n", msv_strerror (ctx, x));
@@ -66,6 +73,10 @@ main (int argc, char **argv)
     "xHMcOGjzfj0LUSqVEVe/D8VzeTEQiNs1MVuRtpQ/dciEL2dkXqjzZiuuhs6TIvDG\n"
     "6wknKthAJdFSXGQkb7kGiw==\n" "-----END CERTIFICATE-----\n";
   x = msv_query_agent (ctx, query, &response);
+  if (!response) {
+      printf ("MSV query: failure contacting MSV agent\n");
+      exit (2);
+  }
   printf ("MSV query: %s\nValid: %s\nMessage: %s\n", msv_strerror (ctx, x),
          response->valid ? "true" : "false", response->message);




On Thu, Mar 13, 2014 at 6:23 PM, Clint Adams <clint at debian.org> wrote:

> On Thu, Mar 13, 2014 at 02:01:00PM -0700, Ramkumar Chinchani wrote:
> > Also noticed that msv.c has a few more malloc's and strdup's without
> proper
> > out-of-memory handling.
>
> Thanks, pushed with whitespace changes.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140318/c524a926/attachment-0001.html>

From dkg at fifthhorseman.net  Tue Mar 18 22:18:01 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 18 Mar 2014 17:18:01 -0400
Subject: [mod_gnutls-devel] msv_ctxt_init() cleanup
In-Reply-To: <CANCUUtDLzyUAb7Z0ufXP=VMgBwYLWZ-Epj=tBOsSVKDmFSpb_w@mail.gmail.com>
References: <CANCUUtA_KTmdHRq3iNO+RZ1-izBSNgPesnRtXTDKmX49C=HMHQ@mail.gmail.com>
 <20140314012358.GA28600@scru.org>
 <CANCUUtDLzyUAb7Z0ufXP=VMgBwYLWZ-Epj=tBOsSVKDmFSpb_w@mail.gmail.com>
Message-ID: <5328B809.8020509@fifthhorseman.net>

Hi Ramkumar--

I think the message below is about libmsv, not mod_gnutls, right?

I'm fine using this mailing list to discuss libmsv work (though if Clint
would prefer it happen somewhere else, i defer to his preference), but
please make it clear which project a patch applies to in the message
someplace to avoid confusion.

(one comment inline, below)

On 03/18/2014 05:09 PM, Ramkumar Chinchani wrote:
> Test code cleanup after recent code changes.
> 
> diff --git a/checkmsva.c b/checkmsva.c
> index 1c64977..aaa3133 100644
> --- a/checkmsva.c
> +++ b/checkmsva.c
> @@ -17,6 +17,7 @@
> 
>  #include <stdlib.h>
>  #include <stdio.h>
> +#include <signal.h>
> 
>  #include "msv/msv.h"
> 

signal.h doesn't seem to be needed by the rest of this patch; does it
belong in a different changeset?

Thanks for your attention to detail, keep these patches coming!

Regards,

	--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/20140318/6741a38f/attachment.sig>

From ramkumar.chinchani at gmail.com  Tue Mar 18 23:06:34 2014
From: ramkumar.chinchani at gmail.com (Ramkumar Chinchani)
Date: Tue, 18 Mar 2014 15:06:34 -0700
Subject: [mod_gnutls-devel] msv_ctxt_init() cleanup
In-Reply-To: <5328B809.8020509@fifthhorseman.net>
References: <CANCUUtA_KTmdHRq3iNO+RZ1-izBSNgPesnRtXTDKmX49C=HMHQ@mail.gmail.com>
 <20140314012358.GA28600@scru.org>
 <CANCUUtDLzyUAb7Z0ufXP=VMgBwYLWZ-Epj=tBOsSVKDmFSpb_w@mail.gmail.com>
 <5328B809.8020509@fifthhorseman.net>
Message-ID: <CANCUUtAjeA4Q=mvVraVX5puq3jAq1zNyk8RHLnaEAgxavpCjOg@mail.gmail.com>

Yes, this is a libmsv patch (can post in a different forum in future should
Clint prefer so)

And the following is not needed.
> +#include <signal.h>

The following is the final patch in the current series I am working on for
libmsv.
Also running valgrind (with limited testing) shows that there are no memory
leaks now.

cURL's WRITEFUNCTION is only called when there is data, so returning a ZERO
when malloc fails should cause a write abort [1]

[1] http://curl.haxx.se/libcurl/c/curl_easy_setopt.html

Thanks.

diff --git a/msv.c b/msv.c
index bd23c0a..fcc55a6 100644
--- a/msv.c
+++ b/msv.c
@@ -64,6 +64,8 @@ write_function (void *ptr, size_t size, size_t nmemb,
void *userdata)
   char *ud;

   ud = malloc (size * nmemb + 1);
+  if (!ud)
+      return 0;
   memcpy (ud, ptr, size * nmemb);

   ud[size * nmemb] = '\0';
@@ -292,6 +294,12 @@ msv_query_agent (msv_ctxt_t ctx, struct msv_query q,

   oldurllen = strlen (ctx->socket_location);
   reviewurl = malloc (oldurllen + 12);
+  if (!reviewurl)
+    {
+        curl_easy_cleanup (c);
+        free (req);
+        return LIBMSV_ERROR_NOMEM;
+    }
   sprintf (reviewurl, "%s%s", ctx->socket_location, "/reviewcert");

   cc = curl_easy_setopt (c, CURLOPT_URL, reviewurl);



On Tue, Mar 18, 2014 at 2:18 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net>wrote:

> Hi Ramkumar--
>
> I think the message below is about libmsv, not mod_gnutls, right?
>
> I'm fine using this mailing list to discuss libmsv work (though if Clint
> would prefer it happen somewhere else, i defer to his preference), but
> please make it clear which project a patch applies to in the message
> someplace to avoid confusion.
>
> (one comment inline, below)
>
> On 03/18/2014 05:09 PM, Ramkumar Chinchani wrote:
> > Test code cleanup after recent code changes.
> >
> > diff --git a/checkmsva.c b/checkmsva.c
> > index 1c64977..aaa3133 100644
> > --- a/checkmsva.c
> > +++ b/checkmsva.c
> > @@ -17,6 +17,7 @@
> >
> >  #include <stdlib.h>
> >  #include <stdio.h>
> > +#include <signal.h>
> >
> >  #include "msv/msv.h"
> >
>
> signal.h doesn't seem to be needed by the rest of this patch; does it
> belong in a different changeset?
>
> Thanks for your attention to detail, keep these patches coming!
>
> Regards,
>
>         --dkg
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140318/05cd82dd/attachment.html>

From clint at debian.org  Wed Mar 19 16:41:32 2014
From: clint at debian.org (Clint Adams)
Date: Wed, 19 Mar 2014 15:41:32 +0000
Subject: [mod_gnutls-devel] msv_ctxt_init() cleanup
In-Reply-To: <CANCUUtAjeA4Q=mvVraVX5puq3jAq1zNyk8RHLnaEAgxavpCjOg@mail.gmail.com>
 <5328B809.8020509@fifthhorseman.net>
 <CANCUUtDLzyUAb7Z0ufXP=VMgBwYLWZ-Epj=tBOsSVKDmFSpb_w@mail.gmail.com>
Message-ID: <20140319154132.GC20350@scru.org>

On Tue, Mar 18, 2014 at 02:09:41PM -0700, Ramkumar Chinchani wrote:
> Test code cleanup after recent code changes.
 
On Tue, Mar 18, 2014 at 05:18:01PM -0400, Daniel Kahn Gillmor wrote:
> I'm fine using this mailing list to discuss libmsv work (though if Clint
> would prefer it happen somewhere else, i defer to his preference), but

Works for me.

On Tue, Mar 18, 2014 at 03:06:34PM -0700, Ramkumar Chinchani wrote:
> The following is the final patch in the current series I am working on for
> libmsv.

Both patches applied and pushed.  Thanks.


From ramkumar.chinchani at gmail.com  Wed Mar 19 19:06:05 2014
From: ramkumar.chinchani at gmail.com (Ramkumar Chinchani)
Date: Wed, 19 Mar 2014 11:06:05 -0700
Subject: [mod_gnutls-devel] mgs_hook_authz() handling of return values
 from mgs_cert_verify()?
In-Reply-To: <53237482.8060105@fifthhorseman.net>
References: <CANCUUtD+Lbb2RY2=txNs+Dx--_JrzCBatxz4OjArRLG_q_5_nQ@mail.gmail.com>
 <53237482.8060105@fifthhorseman.net>
Message-ID: <CANCUUtCnTGxjFaH2hB3C=gDeGRb6HG+DEoqdVi=Ddxx1FpoBnw@mail.gmail.com>

I cannot get the test code to run - various versions of gnutls-cli keep
barfing at me.

Noticed that there is already test code that tests for client verification.

However IINM "t/tests/11_basic_client_verification_fail" only tests the
case where the client doesn't send a certificate at all and not the case
where the certificate sent cannot be verified by the server.

Here is a first draft of this test case which should fail before the patch
in [1] is applied since we expect the test itself to fail. Once the patch
is applied, client should correctly get a HTTP_FORBIDDEN.

[1] http://lists.gnupg.org/pipermail/mod_gnutls-devel/2014-March/000054.html



diff --git a/t/tests/18_basic_client_verification_fail2/apache.conf
b/t/tests/18_basic_client_verification_fail2/apache.conf
new file mode 100644
index 0000000..aec01d9
--- /dev/null
+++ b/t/tests/18_basic_client_verification_fail2/apache.conf
@@ -0,0 +1,13 @@
+Include ${PWD}/../../base_apache.conf
+
+GnuTLSCache dbm cache/gnutls_cache
+
+<VirtualHost ${TEST_IP}:${TEST_PORT}>
+ ServerName ${TEST_HOST}
+ GnuTLSEnable On
+ GnuTLSCertificateFile server/x509.pem
+ GnuTLSKeyFile server/secret.key
+ GnuTLSPriorities NORMAL
+ GnuTLSClientCAFile authority/x509.pem
+ GnuTLSClientVerify require
+</VirtualHost>
diff --git a/t/tests/18_basic_client_verification_fail2/fail.client
b/t/tests/18_basic_client_verification_fail2/fail.client
new file mode 100644
index 0000000..e69de29
diff --git a/t/tests/18_basic_client_verification_fail2/gnutls-cli.args
b/t/tests/18_basic_client_verification_fail2/gnutls-cli.args
new file mode 100644
index 0000000..23f74f1
--- /dev/null
+++ b/t/tests/18_basic_client_verification_fail2/gnutls-cli.args
@@ -0,0 +1,4 @@
+--x509certfile=../../impostor/x509.pem
+--x509keyfile=../../impostor/secret.key
+--x509cafile=../../authority/x509.pem
+--priority=NORMAL
diff --git a/t/tests/18_basic_client_verification_fail2/input
b/t/tests/18_basic_client_verification_fail2/input
new file mode 100644
index 0000000..9ba3394
--- /dev/null
+++ b/t/tests/18_basic_client_verification_fail2/input
@@ -0,0 +1,3 @@
+GET /test.txt HTTP/1.1
+Host: __HOSTNAME__
+




On Fri, Mar 14, 2014 at 2:28 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net>wrote:

> On 03/14/2014 02:58 AM, Ramkumar Chinchani wrote:
> > When GnuTLSClientVerify method is set to cartel or msva,
> mgs_cert_verify()
> > correctly returns HTTP_FORBIDDEN when verification fails.
> >
> > However, when GnuTLSClientVerify is set to "require" at server-level and
> > not at directory-level, mgs_hook_authz() doesn't seem to honor the return
> > code properly for this case.
> >
> > Kindly review the following patch.
> >
> > diff --git a/src/gnutls_hooks.c b/src/gnutls_hooks.c
> > index d068ebb..5bfc2b6 100644
> > --- a/src/gnutls_hooks.c
> > +++ b/src/gnutls_hooks.c
> > @@ -878,7 +878,8 @@ int mgs_hook_authz(request_rec * r) {
> >          rv = mgs_cert_verify(r, ctxt);
> >          if (rv != DECLINED &&
> >                  (rv != HTTP_FORBIDDEN ||
> > -                dc->client_verify_mode == GNUTLS_CERT_REQUIRE)) {
> > +                dc->client_verify_mode == GNUTLS_CERT_REQUIRE ||
> > +                ctxt->sc->client_verify_mode == GNUTLS_CERT_REQUIRE)) {
> >              return rv;
> >          }
> >      }
>
>
> Thanks, Ramkumar!  it sounds like you've got a couple test cases in mind
> for this.  can you add new test cases to avoid this kind of breakage in
> the future?  It seems funny to introduce two test cases to verify a
> 3-line patch, but they should help us avoid seeing this problem crop up
> again in the future.
>
>         --dkg
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140319/92342688/attachment.html>

From ramkumar.chinchani at gmail.com  Wed Mar 19 23:19:42 2014
From: ramkumar.chinchani at gmail.com (Ramkumar Chinchani)
Date: Wed, 19 Mar 2014 15:19:42 -0700
Subject: [mod_gnutls-devel] msv_ctxt_init() cleanup
In-Reply-To: <20140319154132.GC20350@scru.org>
References: <CANCUUtAjeA4Q=mvVraVX5puq3jAq1zNyk8RHLnaEAgxavpCjOg@mail.gmail.com>
 <5328B809.8020509@fifthhorseman.net>
 <CANCUUtDLzyUAb7Z0ufXP=VMgBwYLWZ-Epj=tBOsSVKDmFSpb_w@mail.gmail.com>
 <20140319154132.GC20350@scru.org>
Message-ID: <CANCUUtDeXCp8Ln_5uf7odRcq2xE6XzzWw-YMg-FMgU1u5TqGiw@mail.gmail.com>

[removing Clint from this thread]

Here is the mod_gnutls-side patch to properly handle this.
Can be consumed now although will really take effect only after upstream
libmsv fix.
mod_gnutls no longer crashes on various related failures.

Added a "rv" fix also (feel free to change this), so that HTTP_FORBIDDEN is
returned in this case as well and the caller can decide what needs to do
with it. Again [1] is relevant.

[1] http://lists.gnupg.org/pipermail/mod_gnutls-devel/2014-March/000054.html

diff --git a/src/gnutls_hooks.c b/src/gnutls_hooks.c
index d068ebb..dc5e98f 100644
--- a/src/gnutls_hooks.c
+++ b/src/gnutls_hooks.c
@@ -1198,6 +1198,14 @@ static int mgs_cert_verify(request_rec * r,
mgs_handle_t * ctxt) {
             size_t len = sizeof (cert_pem_buf);

             rv = 0;
+            if (!ctx) {
+                ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
+                              "MSV: Could not initialize context");
+                status = GNUTLS_CERT_INVALID;
+                rv = GNUTLS_E_MEMORY_ERROR;
+                break;
+            }
+
             if (gnutls_x509_crt_export(cert.x509[0], GNUTLS_X509_FMT_PEM,
cert_pem_buf, &len) >= 0) {
                 /* FIXME : put together a name from the cert we received,
instead of hard-coding this value: */
                 q.peername = mgs_x509_construct_uid(r, cert.x509[0]);
@@ -1209,6 +1217,7 @@ static int mgs_cert_verify(request_rec * r,
mgs_handle_t * ctxt) {
                     ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
                                   "GnuTLS: Monkeysphere validation failed:
(message: %s)", resp->message);
                     status = GNUTLS_CERT_INVALID;
+                    rv = GNUTLS_E_CERTIFICATE_ERROR;
                 } else {
                     ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
                                   "GnuTLS: Error communicating with the
Monkeysphere Validation Agent: (%d) %s", rv, msv_strerror(ctx, rv));



On Wed, Mar 19, 2014 at 8:41 AM, Clint Adams <clint at debian.org> wrote:

> On Tue, Mar 18, 2014 at 02:09:41PM -0700, Ramkumar Chinchani wrote:
> > Test code cleanup after recent code changes.
>
> On Tue, Mar 18, 2014 at 05:18:01PM -0400, Daniel Kahn Gillmor wrote:
> > I'm fine using this mailing list to discuss libmsv work (though if Clint
> > would prefer it happen somewhere else, i defer to his preference), but
>
> Works for me.
>
> On Tue, Mar 18, 2014 at 03:06:34PM -0700, Ramkumar Chinchani wrote:
> > The following is the final patch in the current series I am working on
> for
> > libmsv.
>
> Both patches applied and pushed.  Thanks.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140319/5ebe0662/attachment-0001.html>

From ramkumar.chinchani at gmail.com  Thu Mar 20 04:08:03 2014
From: ramkumar.chinchani at gmail.com (Ramkumar Chinchani)
Date: Wed, 19 Mar 2014 20:08:03 -0700
Subject: [mod_gnutls-devel] Add support for GnuTLSClientVerifyMethod=msva
	for OpenPGP certs
Message-ID: <CANCUUtC1CWoK+hLSymR09Y4k5qjy9fAUReUgs+MozN9ibQFabA@mail.gmail.com>

diff --git a/src/gnutls_hooks.c b/src/gnutls_hooks.c
index d068ebb..85c9585 100644
--- a/src/gnutls_hooks.c
+++ b/src/gnutls_hooks.c
@@ -1245,10 +1245,70 @@ static int mgs_cert_verify(request_rec * r,
mgs_handle_t * ctxt) {
             break;
 #ifdef ENABLE_MSVA
         case mgs_cvm_msva:
-            /* need to set status and rv */
-            ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
-                          "GnuTLS:  OpenPGP verification via MSVA is not
yet implemented");
-            rv = GNUTLS_E_UNIMPLEMENTED_FEATURE;
+        {
+            struct msv_response* resp = NULL;
+            struct msv_query q = { .context="https", .peertype="client",
.pkctype="openpgp4fpr" };
+            msv_ctxt_t ctx = msv_ctxt_init(NULL);
+            char fpr[32];
+            size_t fprlen = sizeof (fpr);
+
+            rv = 0;
+            if (!ctx) {
+                ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
+                              "MSV: Could not initialize context");
+                status = GNUTLS_CERT_INVALID;
+                rv = GNUTLS_E_MEMORY_ERROR;
+                break;
+            }
+
+            if (gnutls_openpgp_crt_get_fingerprint(cert.pgp, fpr, &fprlen)
>= 0) {
+                gnutls_datum_t d = {.data = (unsigned char *)fpr, .size =
fprlen};
+                char buf[64];
+                size_t buflen = sizeof(buf);
+
+                if (gnutls_hex_encode(&d, buf, &buflen) >= 0) {
+                    char name[1024];
+                    size_t namelen = sizeof (name);
+
+                    if (gnutls_openpgp_crt_get_name(cert.pgp, 0, name,
&namelen) >= 0) {
+                        q.peername = name;
+                        q.pkcdata = buf;
+                        rv = msv_query_agent(ctx, q, &resp);
+                        if (rv == LIBMSV_ERROR_SUCCESS) {
+                            status = 0;
+                        } else if (rv == LIBMSV_ERROR_INVALID) {
+                            ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
+                                    "GnuTLS: Monkeysphere validation
failed: (message: %s)", resp->message);
+                            status = GNUTLS_CERT_INVALID;
+                            rv = GNUTLS_E_CERTIFICATE_ERROR;
+                        } else {
+                            ap_log_rerror(APLOG_MARK, APLOG_DEBUG, 0, r,
+                                    "GnuTLS: Error communicating with the
Monkeysphere Validation Agent: (%d) %s", rv, msv_strerror(ctx, rv));
+                            status = GNUTLS_CERT_INVALID;
+                            rv = -1;
+                        }
+                    } else {
+                        ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
+                                "GnuTLS: Could not get name from the
client certificate or name too long");
+                        status = GNUTLS_CERT_INVALID;
+                        rv = -1;
+                    }
+                } else {
+                    ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
+                            "GnuTLS: Could not convert fingerprint");
+                    status = GNUTLS_CERT_INVALID;
+                    rv = -1;
+                    break;
+                }
+            } else {
+                ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
+                              "GnuTLS: Could not get fingerprint from
client certificate");
+                status = GNUTLS_CERT_INVALID;
+                rv = -1;
+            }
+            msv_response_destroy(resp);
+            msv_ctxt_destroy(ctx);
+        }
             break;
 #endif
         default:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140319/2cf56853/attachment.html>

From ramkumar.chinchani at gmail.com  Fri Mar 21 01:21:20 2014
From: ramkumar.chinchani at gmail.com (Ramkumar Chinchani)
Date: Thu, 20 Mar 2014 17:21:20 -0700
Subject: [mod_gnutls-devel] Add a MSVA sanity check during module load time
Message-ID: <CANCUUtDTqqPC4XrdKZcinVfU7cv+Yn2khXMKeYvGjPiiwf=uYg@mail.gmail.com>

If apache is started as "root", then the following is needed

MSVA_ALLOWED_USERS="0" monkeysphere-validation-agent

Of course, MSVA daemon may fail later but at least we can eliminate
configuration errors.

diff --git a/src/gnutls_config.c b/src/gnutls_config.c
index 3300854..4a6a648 100644
--- a/src/gnutls_config.c
+++ b/src/gnutls_config.c
@@ -19,6 +19,9 @@

 #include "mod_gnutls.h"
 #include "apr_lib.h"
+#ifdef ENABLE_MSVA
+#include "msv/msv.h"
+#endif

 #ifdef APLOG_USE_MODULE
 APLOG_USE_MODULE(gnutls);
@@ -375,6 +378,19 @@ const char *mgs_set_client_verify_method(cmd_parms *
parms, void *dummy,
         sc->client_verify_method = mgs_cvm_cartel;
     } else if (strcasecmp("msva", arg) == 0) {
 #ifdef ENABLE_MSVA
+        /* check if MSV is setup properly */
+        msv_ctxt_t ctx = msv_ctxt_init(NULL);
+        if (!ctx) {
+            return "MSV: Unable to initialize context";
+        }
+
+        int ret = msv_check_msva(ctx);
+        if (ret != LIBMSV_ERROR_SUCCESS) {
+            msv_ctxt_destroy(ctx);
+            return "MSV: Unable to check msva";
+        }
+        msv_ctxt_destroy(ctx);
+
         sc->client_verify_method = mgs_cvm_msva;
 #else
         return "GnuTLSClientVerifyMethod: msva is not supported";
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/attachments/20140320/d220ba14/attachment.html>