[openssl-dev] Backporting opaque struct getter/setter functions

[Benjamin Kaduk]

To revitalize an old thread (quoted below but summarized here), some
applications may desire source-code compatibility between the 1.0.2 API
and the 1.1.0 API.  It seems like the sense of the team is that such
accessor functions (or macros) should not be committed into the official
1.0.2 tree, but that the community could maintain an external
compatibility shim.  Is that correct?

Does anyone already have such a compatibility header, or thoughts about
where it should/could reside?

We have been noticing that a lot of accessor implementations can be
backported as static inline functions to a compatibility header or
headers with no further modification.  (But not all, as, e.g., HMAC_CTX
has changed to hold pointers instead of embedded structs.)

-Ben

On 01/11/2016 01:20 PM, Matt Caswell wrote:
>
> On 11/01/16 18:29, Viktor Dukhovni wrote:
>>> On Jan 11, 2016, at 5:23 AM, Tomas Mraz <tmraz at redhat.com> wrote:
>>>
>>> On Po, 2016-01-11 at 01:09 +0000, Peter Waltenberg wrote:
>>>> The point of using accessor FUNCTIONS is that the code doesn't break
>>>> if the structure size or offsets of fields in the underlying
>>>> structures change across binaries.
>>>>
>>>> Where that mainly has an impact is updating the crypto/ssl libs
>>>> underneath existing binaries is more likely to just work.
>>>>
>>>> #defines in the headers do not help at all here.
>>>>
>>> The point is in achieving reverse API compatibility between 1.1 and
>>> 1.0.2. No binary compatibility is expected between those branches.
>>>
>>> I think that having the API compatibility would be really useful thing
>>> easing porting application code to 1.1 branch.
>> Yes, although in practice may users of 1.0.x will have previous releases
>> that don't have the accessors, so the issue is difficult to address
>> retroactively in OpenSSL.  In Postfix, I add the macros myself:
>>
>> #if OPENSSL_VERSION_NUMBER < 0x10100000L
>> #define X509_up_ref(x) (CRYPTO_add(&x->references, 1, CRYPTO_LOCK_X509))
>> #endif
>>
>> Which means that interestingly enough adding these to 1.0.x would break
>> my code and similar code elsewhere.
>>
>> So on the whole forward-compatibility macros don't fully address the
>> problem, and may do as much harm as good.
>>
>> I think that applications porting to 1.1.0 can and should implement
>> their own macros against a stable 1.0.x API that we don't change
>> at the last minute.  Providing your own forward-compatible glue
>> is easy enough...
>>
> Perhaps someone from the community could contribute a (separately
> maintained) compatibility layer to provide the relevant macros?
>
> Matt
> _______________________________________________
> openssl-dev mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161103/6538422b/attachment-0001.html>