Backporting opaque struct getter/setter functions

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Backporting opaque struct getter/setter functions

Paul Kehrer
With OpenSSL 1.1.0 opaquing most of the structs getter/setter functions are required to perform many operations. What do people think about backporting those accessors into the 1.0.2 branch? It might simplify supporting 1.1.0 (but only as projects drop 0.9.8/1.0.0/1.0.1 support of course).

-Paul Kehrer
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Backporting opaque struct getter/setter functions

Salz, Rich

> required to perform many operations. What do people think about
> backporting those accessors into the 1.0.2 branch?

Another possibility is to have a just a single (new) header file that has #define's for the accessors that turn into raw structure access.
_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Backporting opaque struct getter/setter functions

Richard Moore


On 9 January 2016 at 22:45, Salz, Rich <[hidden email]> wrote:

> required to perform many operations. What do people think about
> backporting those accessors into the 1.0.2 branch?

Another possibility is to have a just a single (new) header file that has #define's for the accessors that turn into raw structure access.


​That would not help anyone who needs function pointers.​
 

​Rich.


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Backporting opaque struct getter/setter functions

Peter Waltenberg
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.


Peter


-----"openssl-dev" <[hidden email]> wrote: -----
To: [hidden email]
From: Richard Moore
Sent by: "openssl-dev"
Date: 01/10/2016 11:20AM
Subject: Re: [openssl-dev] Backporting opaque struct getter/setter functions



On 9 January 2016 at 22:45, Salz, Rich <[hidden email]> wrote:

> required to perform many operations. What do people think about
> backporting those accessors into the 1.0.2 branch?

Another possibility is to have a just a single (new) header file that has #define's for the accessors that turn into raw structure access.


​That would not help anyone who needs function pointers.​
 

​Rich.

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Backporting opaque struct getter/setter functions

Judson Wilson
If some users find 1.1 to be a worse alternative to 1.0.2, but they have the power to use a very new version of 1.0.2, then this makes sense for reverse compatibility.

On Sun, Jan 10, 2016 at 5:09 PM, Peter Waltenberg <[hidden email]> 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.


Peter


-----"openssl-dev" <[hidden email]> wrote: -----
To: [hidden email]
From: Richard Moore
Sent by: "openssl-dev"
Date: 01/10/2016 11:20AM
Subject: Re: [openssl-dev] Backporting opaque struct getter/setter functions




On 9 January 2016 at 22:45, Salz, Rich <[hidden email]> wrote:

> required to perform many operations. What do people think about
> backporting those accessors into the 1.0.2 branch?

Another possibility is to have a just a single (new) header file that has #define's for the accessors that turn into raw structure access.


​That would not help anyone who needs function pointers.​
 

​Rich.

_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev



_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Backporting opaque struct getter/setter functions

Tomas Mraz-2
In reply to this post by Peter Waltenberg
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.

--
Tomas Mraz
No matter how far down the wrong road you've gone, turn back.
                                              Turkish proverb
(You'll never know whether the road is wrong though.)



_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Backporting opaque struct getter/setter functions

Viktor Dukhovni

> On Jan 11, 2016, at 5:23 AM, Tomas Mraz <[hidden email]> 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...

--
        Viktor.


_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Backporting opaque struct getter/setter functions

Viktor Dukhovni
In reply to this post by Peter Waltenberg

> On Jan 10, 2016, at 8:09 PM, Peter Waltenberg <[hidden email]> 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.

Well, this is why 1.1.0 is switching to functions, and making
the structures opaque.  As a result 1.1.0 is NOT binary
compatible with 1.0.x.  It is too late to change 1.0.x.

It will be easier to maintain a stable ABI starting with 1.1.0.
Switching from 1.0.x to 1.1.0 will require re-compilation, and
some source code changes.

--
        Viktor.



_______________________________________________
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Backporting opaque struct getter/setter functions

Matt Caswell-2
In reply to this post by Viktor Dukhovni


On 11/01/16 18:29, Viktor Dukhovni wrote:

>
>> On Jan 11, 2016, at 5:23 AM, Tomas Mraz <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: 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 [hidden email] 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


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Backporting opaque struct getter/setter functions

Salz, Rich

I hope that Daniel from CURL will speak up, and perhaps Richard from Qt.

 

I think a new header file, like “openssl110compat.h” or something, hosted in a public repo would be great.  We could point to it in the 1.0.2 README, for example.

 

-- 

Senior Architect, Akamai Technologies

Member, OpenSSL Dev Team

IM: [hidden email] Twitter: RichSalz


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Backporting opaque struct getter/setter functions

Douglas E Engert
In reply to this post by Benjamin Kaduk


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




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 [hidden email] 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




-- 

 Douglas E. Engert  [hidden email]
 

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: 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
// "One if by land, two if by sea, three if by the Internet."

On Nov 3, 2016, at 4:31 PM, Douglas E Engert <[hidden email]> 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




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 [hidden email] 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




-- 

 Douglas E. Engert  [hidden email]
 
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Backporting opaque struct getter/setter functions

Kurt Roeckx
In reply to this post by Benjamin Kaduk
On Thu, Nov 03, 2016 at 03:11:10PM -0500, 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?

I put a bunch I've used before on the wiki, which might not be
ideal.


Kurt

--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Reply | Threaded
Open this post in threaded view
|

Re: Backporting opaque struct getter/setter functions

Hubert Kario
In reply to this post by Short, Todd
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
> // [hidden email]<mailto:[hidden email]>
> // "One if by land, two if by sea, three if by the Internet."
>
> On Nov 3, 2016, at 4:31 PM, Douglas E Engert
> <[hidden email]<mailto:[hidden email]>> 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
> <[hidden email]><mailto:[hidden email]> 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  <[hidden email]><mailto:[hidden email]>
>
>
>
> --
> 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
--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Backporting opaque struct getter/setter functions

Short, Todd
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 specifically provisions #1 and #6.

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

On Nov 8, 2016, at 7:04 AM, Hubert Kario <[hidden email]> 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
// [hidden email]<[hidden email]>
// "One if by land, two if by sea, three if by the Internet."

On Nov 3, 2016, at 4:31 PM, Douglas E Engert
<[hidden email]<[hidden email]>> 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
<[hidden email]><mailto:[hidden email]> 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  <[hidden email]><mailto:[hidden email]>



--
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


--
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev

signature.asc (859 bytes) Download Attachment