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 > // tsh...@akamai.com<mailto:tsh...@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 > <deeng...@gmail.com<mailto:deeng...@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 > <tm...@redhat.com><mailto:tm...@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 <deeng...@gmail.com><mailto:deeng...@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
signature.asc
Description: This is a digitally signed message part.
-- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
