On Sun, Aug 02, 2015 at 09:33:48AM +0200, Kaspar Brand wrote:
> On 19.07.2015 17:24, Kaspar Brand wrote:
> > But, to be on the safe side, I think we could a) move the OBJ_create()
> > call to ssl_hook_pre_config and b) omit OBJ_cleanup(). Do you concur?
>
> For the record: I have now committed thi
On Sun, Aug 02, 2015 at 09:33:48AM +0200, Kaspar Brand wrote:
> On 19.07.2015 17:24, Kaspar Brand wrote:
> > But, to be on the safe side, I think we could a) move the OBJ_create()
> > call to ssl_hook_pre_config and b) omit OBJ_cleanup(). Do you concur?
>
> For the record: I have now committed thi
On 19.07.2015 17:24, Kaspar Brand wrote:
> But, to be on the safe side, I think we could a) move the OBJ_create()
> call to ssl_hook_pre_config and b) omit OBJ_cleanup(). Do you concur?
For the record: I have now committed this to trunk with r1693792.
Kaspar
On 13.07.2015 16:03, Joe Orton wrote:
> On Sat, Jul 11, 2015 at 04:40:20PM +0200, Kaspar Brand wrote:
>> @@ -1902,5 +1907,7 @@ apr_status_t ssl_init_ModuleKill(void *data)
>>
>> free_dh_params();
>>
>> +OBJ_cleanup();
>> +
>> return APR_SUCCESS;
>
> From being burnt previously th
On Sat, Jul 11, 2015 at 04:40:20PM +0200, Kaspar Brand wrote:
> @@ -1902,5 +1907,7 @@ apr_status_t ssl_init_ModuleKill(void *data)
>
> free_dh_params();
>
> +OBJ_cleanup();
> +
> return APR_SUCCESS;
>From being burnt previously three or four times, I get scared by OpenSSL
proces
On Sat, Jul 11, 2015 at 04:40:20PM +0200, Kaspar Brand wrote:
> On 29.06.2015 15:14, Jan Pazdziora wrote:
> > How about just passing char * and doing all the mapping logic
> > including possible OBJ_create in parse_otherName_value? My goal here
> > is to have all the "hard" work of determining the
On 29.06.2015 15:14, Jan Pazdziora wrote:
> How about just passing char * and doing all the mapping logic
> including possible OBJ_create in parse_otherName_value? My goal here
> is to have all the "hard" work of determining the semantics isolated
> in one place.
>
> Please see patch attached.
Yo
On 06/29/2015 03:14 PM, Jan Pazdziora wrote:
On Mon, Jun 29, 2015 at 01:47:45PM +0200, Jan Pazdziora wrote:
On Sun, Jun 28, 2015 at 05:11:57PM +0200, Kaspar Brand wrote:
On 22.06.2015 10:37, Jan Pazdziora wrote:
Please find a new patch attached which I hope covers all the
parts you've outlined
On Mon, Jun 29, 2015 at 01:47:45PM +0200, Jan Pazdziora wrote:
> On Sun, Jun 28, 2015 at 05:11:57PM +0200, Kaspar Brand wrote:
> > On 22.06.2015 10:37, Jan Pazdziora wrote:
> > > Please find a new patch attached which I hope covers all the
> > > parts you've outlined, for SSL_CLIENT_SAN_OTHER_msUPN
On Sun, Jun 28, 2015 at 05:11:57PM +0200, Kaspar Brand wrote:
> On 22.06.2015 10:37, Jan Pazdziora wrote:
> > Please find a new patch attached which I hope covers all the
> > parts you've outlined, for SSL_CLIENT_SAN_OTHER_msUPN_*.
>
> Thanks. Your implementation assumes that only a single otherNa
On 22.06.2015 10:37, Jan Pazdziora wrote:
> Please find a new patch attached which I hope covers all the
> parts you've outlined, for SSL_CLIENT_SAN_OTHER_msUPN_*.
Thanks. Your implementation assumes that only a single otherName form
(msUPN) needs to be supported, but I would prefer to code it in
On Sun, Jun 21, 2015 at 08:55:02AM +0200, Kaspar Brand wrote:
>
> The point with the otherName SAN type is that it's yet another bag of
> potentially arbitrary ASN.1 stuff, actually (not just simple strings, as
> is the case for rfc822Name or dNSName):
>
>GeneralName ::= CHOICE {
> ot
On 19.06.2015 16:51, Jan Pazdziora wrote:
> On Thu, Jun 18, 2015 at 12:22:21PM +0200, Yann Ylavic wrote:
>> I think a more generic way would to have something like
>> SSL_CLIENT_OID__n, so that we wouldn't have to add a new field
>> each time.
>> In this case, that would be: SSL_CLIENT_OID_1.3.6.1.
On Thu, Jun 18, 2015 at 12:22:21PM +0200, Yann Ylavic wrote:
> On Thu, Jun 18, 2015 at 11:49 AM, Jan Pazdziora wrote:
> >
> > I'd appreciate any comments about suitability of such change, as well
> > as the implementation. Specifically, I'm not sure if people will
> > prefer the generic and curren
On Fri, Jun 19, 2015 at 11:56 AM, Yann Ylavic wrote:
>
> Instead of SSL_CLIENT_OID_, we could also have something like
> SSL_CLIENTn since the underlying mod_ssl
> code handles both (IIRC).
> I don't know if SAN_otherName/UPN have a short/long name though, but many
> have.
Nope, SAN as an oi
On Fri, Jun 19, 2015 at 11:32 AM, Jan Kaluža wrote:
> On 06/18/2015 12:22 PM, Yann Ylavic wrote:
>>
>> On Thu, Jun 18, 2015 at 11:49 AM, Jan Pazdziora
>> wrote:
>>>
>>>
>>> I'd appreciate any comments about suitability of such change, as well
>>> as the implementation. Specifically, I'm not sure
On 06/18/2015 12:22 PM, Yann Ylavic wrote:
On Thu, Jun 18, 2015 at 11:49 AM, Jan Pazdziora wrote:
I'd appreciate any comments about suitability of such change, as well
as the implementation. Specifically, I'm not sure if people will
prefer the generic and currently proposed
SSL_CLIEN
On Thu, Jun 18, 2015 at 11:49 AM, Jan Pazdziora wrote:
>
> I'd appreciate any comments about suitability of such change, as well
> as the implementation. Specifically, I'm not sure if people will
> prefer the generic and currently proposed
>
> SSL_CLIENT_SAN_otherName_n
>
> which gets any
18 matches
Mail list logo
