<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <br>
    <div class="moz-cite-prefix">On 11/3/2016 3:11 PM, Benjamin Kaduk
      wrote:<br>
    </div>
    <blockquote
      cite="mid:91045f12-b72e-4ad0-40c2-cd084cafad5b@akamai.com"
      type="cite">
      <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
      <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>
      </tt></blockquote>
    <br>
    OpenSC has such a header file to address most of the OpenSSL
    functions used withing OpenSC. <br>
    <br>
<a class="moz-txt-link-freetext" href="https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/sc-ossl-compat.h">https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/sc-ossl-compat.h</a><br>
    <br>
    <tt><br>
      <br>
    </tt>
    <blockquote
      cite="mid:91045f12-b72e-4ad0-40c2-cd084cafad5b@akamai.com"
      type="cite"><tt> <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">
          <blockquote type="cite">
            <pre wrap="">On Jan 11, 2016, at 5:23 AM, Tomas Mraz <a moz-do-not-send="true" 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 moz-do-not-send="true" 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>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="200">-- 

 Douglas E. Engert  <a class="moz-txt-link-rfc2396E" href="mailto:DEEngert@gmail.com"><DEEngert@gmail.com></a>
 
</pre>
  </body>
</html>