On Mon, Feb 14, 2005 at 05:51:50PM +, David Reid wrote:
Joe Orton wrote:
Here's an alternative implementation: does it work for you?
This looks good to me and seems to work as required.
Great!
Care to commit it?
Now done.
joe
Joe Orton wrote:
Here's an alternative implementation: does it work for you?
This looks good to me and seems to work as required.
Care to commit it?
david
Index: ssl_private.h
===
--- ssl_private.h (revision 153210)
+++ ssl_private.h
Joe Orton wrote:
Here's an alternative implementation: does it work for you?
I'll try it out tomorrow as time won't permit me to look at it today.
Looks good though.
david
Index: ssl_private.h
===
--- ssl_private.h (revision
Here's an alternative implementation: does it work for you?
Index: ssl_private.h
===
--- ssl_private.h (revision 153210)
+++ ssl_private.h (working copy)
@@ -641,6 +641,9 @@
/* Variables */
void
On Wed, Feb 02, 2005 at 09:08:02PM +, David Reid wrote:
William A. Rowe, Jr. wrote:
At 04:17 AM 2/2/2005, David Reid wrote:
Basically this allows us to gain access to the actual cert structure.
Agreed that raw cert isn't that useful, and somewhat frightens
me in the environment
Basically this allows us to gain access to the actual cert structure.
Index: ssl_engine_vars.c
===
--- ssl_engine_vars.c (revision 123890)
+++ ssl_engine_vars.c (working copy)
@@ -364,6 +364,10 @@
else if (strcEQ(var, CERT))
On Wed, Feb 02, 2005 at 10:17:04AM +, David Reid wrote:
Basically this allows us to gain access to the actual cert structure.
I don't like the idea of exposing the X509 * directly especially not
through a char * interface. Exposing the DER representation (e.g.
base64-encoded) through
Joe Orton wrote:
On Wed, Feb 02, 2005 at 10:17:04AM +, David Reid wrote:
Basically this allows us to gain access to the actual cert structure.
I don't like the idea of exposing the X509 * directly especially not
through a char * interface. Exposing the DER representation (e.g.
On Wed, Feb 02, 2005 at 11:09:47AM +, David Reid wrote:
Joe Orton wrote:
On Wed, Feb 02, 2005 at 10:17:04AM +, David Reid wrote:
Basically this allows us to gain access to the actual cert structure.
I don't like the idea of exposing the X509 * directly especially not
through a
Joe Orton wrote:
On Wed, Feb 02, 2005 at 11:09:47AM +, David Reid wrote:
Joe Orton wrote:
On Wed, Feb 02, 2005 at 10:17:04AM +, David Reid wrote:
Basically this allows us to gain access to the actual cert structure.
I don't like the idea of exposing the X509 * directly especially not
On Wed, Feb 02, 2005 at 11:36:41AM +, Ben Laurie wrote:
Joe Orton wrote:
On Wed, Feb 02, 2005 at 11:09:47AM +, David Reid wrote:
The issue is a need to get access to the internals of the structure.
By exposing the X509 * directly you expose a dependency on the
underlying SSL
At 04:17 AM 2/2/2005, David Reid wrote:
Basically this allows us to gain access to the actual cert structure.
Agreed that raw cert isn't that useful, and somewhat frightens
me in the environment table. The PEM or DER formats would be
generally useful. Unpacking the extended X509 attributes
William A. Rowe, Jr. wrote:
At 04:17 AM 2/2/2005, David Reid wrote:
Basically this allows us to gain access to the actual cert structure.
Agreed that raw cert isn't that useful, and somewhat frightens
me in the environment table. The PEM or DER formats would be
generally useful. Unpacking the
13 matches
Mail list logo
