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

[Short, Todd]

The file below is LPGL 2.1, and may not be compatible with various projects. Can it be changed to use the OpenSSL license or equivalent?
--
-Todd Short
// tshort at akamai.com<mailto:tshort at akamai.com>
// "One if by land, two if by sea, three if by the Internet."

On Nov 3, 2016, at 4:31 PM, Douglas E Engert <deengert at gmail.com<mailto:deengert at gmail.com>> wrote:



On 11/3/2016 3:11 PM, Benjamin Kaduk wrote:
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?

OpenSC has such a header file to address most of the OpenSSL functions used withing OpenSC.

https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/sc-ossl-compat.h<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_OpenSC_OpenSC_blob_master_src_libopensc_sc-2Dossl-2Dcompat.h&d=DgMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=xoYIrv5R7W7QHyLEdOuyzFJ-b7mHMoeJeaJ6OXIq3Os&s=nIUo0yfKtaVnPewNDTpig52n6Mbim01ii8UnkmQwYLY&e=>




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><mailto: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<https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DgMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=xoYIrv5R7W7QHyLEdOuyzFJ-b7mHMoeJeaJ6OXIq3Os&s=PzZDcf-p6tMpMoz0dw0z21yscvoMGdBrpf08ZD7UAq8&e=>






--

 Douglas E. Engert  <DEEngert at gmail.com><mailto:DEEngert at gmail.com>



--
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/20161107/a1bd8bae/attachment-0001.html>