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

Tue Nov 8 13:49:56 UTC 2016

IANAL, but:

1. Some people see GPL or even LGPL and run away screaming.
1a. Using this means that the using the OpenSSL library requires accepting the LGPL.
1b. Some interpretations of the LGPL permit use when the code is in a dynamically-linked library. Since this is a header file, any code within is compiled into the program in question (not dynamically linked),  as this header contains inline functions, not just function declarations. Anything that uses it cannot be considered a “work that uses the library”, since there is no way for a user to substitute their own version of this header file into a previously compiled program.
2. Under the assumption that some of the code is likely copied from OpenSSL 1.1.0 (because it not necessarily possible to create an identical OpenSSL function from said definition of it), it means that a license change occurred to OpenSSL code, and that is a violation of the OpenSSL license: https://github.com/openssl/openssl/blob/master/LICENSE <https://github.com/openssl/openssl/blob/master/LICENSE> specifically provisions #1 and #6.

--
-Todd Short
// tshort at akamai.com
// "One if by land, two if by sea, three if by the Internet."

> On Nov 8, 2016, at 7:04 AM, Hubert Kario <hkario at redhat.com> wrote:
> 
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161108/ed7a2880/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20161108/ed7a2880/attachment.sig>