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

[Hubert Kario]

On Monday, 7 November 2016 21:26:16 CET Short, Todd wrote:
> 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? 

how LGPL may not be compatible with any project?

> --
> -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_OpenS
> C_blob_master_src_libopensc_sc-2Dossl-2Dcompat.h&d=DgMDaQ&c=96ZbZZcaMF4w0F4j
> pN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=xoYIrv5R7W7QHyLEdOuyz
> FJ-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.pro
> ofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dde
> v&d=DgMDaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAw
> mtRik&m=xoYIrv5R7W7QHyLEdOuyzFJ-b7mHMoeJeaJ6OXIq3Os&s=PzZDcf-p6tMpMoz0dw0z21
> yscvoMGdBrpf08ZD7UAq8&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


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161108/6f113d82/attachment.sig>