<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<tt>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?<br>
<br>
Does anyone already have such a compatibility header, or thoughts
about where it should/could reside?<br>
<br>
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.)<br>
<br>
-Ben<br>
</tt><br>
<div class="moz-cite-prefix">On 01/11/2016 01:20 PM, Matt Caswell
wrote:<br>
</div>
<blockquote cite="mid:5694008D.20502@openssl.org" type="cite">
<pre wrap="">
On 11/01/16 18:29, Viktor Dukhovni wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">On Jan 11, 2016, at 5:23 AM, Tomas Mraz <a class="moz-txt-link-rfc2396E" href="mailto:tmraz@redhat.com"><tmraz@redhat.com></a> wrote:
On Po, 2016-01-11 at 01:09 +0000, Peter Waltenberg wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
<pre wrap="">
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...
</pre>
</blockquote>
<pre wrap="">
Perhaps someone from the community could contribute a (separately
maintained) compatibility layer to provide the relevant macros?
Matt
_______________________________________________
openssl-dev mailing list
To unsubscribe: <a class="moz-txt-link-freetext" href="https://mta.openssl.org/mailman/listinfo/openssl-dev">https://mta.openssl.org/mailman/listinfo/openssl-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>