<div dir="ltr"><div dir="ltr">On Wed, 29 Jun 2022 at 20:33, Simon Chopin <<a href="mailto:simon.chopin@canonical.com">simon.chopin@canonical.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi!<br>
<br>
As part of our efforts to support the Rust toolchain in main, we need to<br>
have libgit2 in main (dependency of cargo). However, it currently links<br>
against mbedTLS for its HTTPS backend rather than OpenSSL, for licensing<br>
reasons IIUC. Those reasons would now be invalid with the new OpenSSL<br>
3.0 licensing.<br>
<br>
I'd like to switch it back to OpenSSL to avoid pulling yet another TLS<br>
implementation in main, however I'm a bit fuzzy whether this would<br>
constitute a breaking change for the libgit2 package. The libgit2<br>
library does not expose anything from its crypto implem as part of its<br>
API, nor does it re-export any of their symbols (assuming I understand<br>
the output of readelf -s correctly).<br>
<br>
Could someone confirm that this does not represent a breaking change?<br></blockquote><div><br></div><div>I can't see any way that the selection of the backend leaks into the ABI in a quick poke around in libgit2. I presume you've built the .so both ways and looked at the dynamic symbol tables? (actually the symbols file probably helps here!)</div><div><br></div><div>If the same names are exported then we'd only be in trouble if the arguments to a function have changed somehow and I can't see how that would happen given the libgit2 headers.</div><div><br></div><div>Cheers,</div><div>mwh</div></div></div>