[openssl-dev] Fwd: Re: [openssl-users] Duplicating const X509_NAME

[Sascha Steinbiss]

Hi Matt,

thanks for your quick reply.

>> Please also see my commit
>> https://github.com/satta/openssl/commit/4392b12a0caa8f8e7df0bb6e1c94de7f744407ba
>> implementing this. Looking forward to some comments -- if you are OK
>> with it I would be happy to file a pull request. My CLA has been signed
>> and emailed to OpenSSL Foundation's legal team.
> 
> Just go ahead a file a pull request anyway...that's the best way of
> getting comments. If changes are needed you can update the PR as required.

Sure, will do.

>> Unfortunately I could not find any existing tests for the get0
>> counterpart in the OpenSSL source. Did I miss something? That's the
>> reason why I haven't included tests yet, having read the contributor's
>> guide.
> 
> Hmmm, there doesn't seem to be anything. You could probably add
> something to test_tlsext_status_type() to test/sslapitest.c.

I just took a look but it looks like the dummy response in that file is
in the wrong format to be decoded to a proper OCSP_RESPONSE.
Unfortunately it's less than trivial -- at least for me -- to come up
with a good test case providing me with the required test data to run
the new method on it. I'd be happy to add tests if someone could provide
some pointers...

Thanks
Sascha

>> -------- Forwarded Message --------
>> Subject: 	Re: [openssl-users] Duplicating const X509_NAME
>> Date: 	Mon, 7 Nov 2016 12:54:03 -0600
>> From: 	Benjamin Kaduk <bkaduk at akamai.com>
>> Reply-To: 	openssl-users at openssl.org
>> To: 	openssl-users at openssl.org
>>
>>
>>
>> On 11/07/2016 05:42 AM, Sascha Steinbiss wrote:
>>> Hi all,
>>>
>>> I was wondering how to properly make a clone of a const X509_NAME in
>>> OpenSSL 1.1?
>>>
>>> In particular, I am obtaining a const X509_NAME* via OCSP_resp_get0_id()
>>> and would like to pass it to X509_find_by_subject() which takes a
>>> X509_NAME* (non-const). I looked into using X509_NAME_dup() to obtain a
>>> local copy -- which looked like the obvious approach -- but that also
>>> only takes a non-const parameter.
>>>
>>> Any ideas? With
>>>
>>
>> Hmm, seems like there may be a need for get1-style accessors, then.
>> Supposedly missing accessors will get backported from master to the 1.1
>> branch (though making it in time for 1.1.0c later this week could be
>> tough).  It might be worth filing a pull request with such things.
>>
>> -Ben
>>
>>
>>