Fix (most) problems with LibreSSL #1673
Conversation
LibreSSL no longer uses compression in ssl.h, so the case that was formerly activated by defining OPENSSL_NO_COMP is now the default, and COMP_METHOD isn't defined (it's defined in comp.h, but that's no longer included by ssl.h). In order to make all the type definitions here line up with what's actually in LibreSSL's ssl.h, define COMP_METHOD as void. This definition is still compatible with the later type declaration in ssl.py: typedef ... COMP_METHOD;
Some features added to newer OpenSSL versions are absent in LibreSSL, so don't mark these as present if LIBRESSL_VERSION_NUMBER is defined.
LibreSSL aims to be source-compatible with OpenSSL, so there is no good reason to fail this test simply because the name has changed.
This changelog entry represents the previous three commits, which all fix compile- or test-time problems running against LibreSSL.
|
Can one of the admins verify this patch? |
|
ok to test |
|
I've submitted the cryptodev patch (referenced in my initial comment) as #1674. |
|
I'm gonna have to say -1 on landing this as I agree with @reaperhulk that LibreSSL should be supported as a different backend since it seems like the LibreSSL team has no intention of preserving compatibility with OpenSSL. Supporting LibreSSL in this manner will probably get increasingly messy. |
|
Test PASSed. |
|
@AnchorCat did Libre add dynamic engine support back in? I thought previous releases had completely removed the engine subsystem? |
|
@Ayrx: Please forgive my noob question, as I'm not a Python programmer, but can that be done in such a way as to reuse the parts which are common (which is currently most of the openssl backend)? It seems equally messy to maintain a copy of all the backend code. @reaperhulk: Referencing the OpenBSD CVS version of engine.h, the declarations of |
|
Hmm, interesting. We've had some other people come through asking for Libre fixes in the past and I gathered the impression that engine support was entirely missing. Clearly that's not the case. Re: alternate backends, the long term concern is that LibreSSL, while close to OpenSSL, appears to be slowly diverging and these conditional checks may ultimately prove to be a burden above and beyond maintaining a (very similar) second backend. Unfortunately right now the alternate backend system isn't really mature enough for use so that's not a serious option. Given the above I'm 👍 on this for now. I think I'm willing to add a LibreSSL builder to prevent regression, but I don't think I want to officially state we support LibreSSL until either a) we've got the tooling in place to support it as a separate backend or b) we're confident they're not going to remove/break any additional APIs. Definitely interested in opinions from other team members here. |
|
One downside to a seperate binding/backend is that things that are "OpenSSL" specific, such as pyOpenSSL won't work with it. I'm broadly happy with the approach here, but strongly agree that we need CI. |
|
Ok, I guess this isn't that messy at the moment and if things start to get hairy we can always refactor. :) We still need to discuss removing cryptodev (#1674) and EGD though, those are technically backward compatibility breaks and pyopenssl may be relying on them existing. |
|
Closing in favor of #1679. |
5 participants
These four commits fix most, but not all of the problems with LibreSSL. On my OpenBSD -current (as of 2015-02-13) system, the cryptography test suite passes with the following patches applied:
I have tried to provide sufficient explanation of what each commit is doing in the individual commit messages, but please let me know if clarification is needed.