Problem with LibreSSL

K

karrakis

Hello There,

I ran into two issues that seems linked to LibreSSL.

First, i m unable to compile mysql80-client and mysql80-server ports, its crashed with : "use of undeclared identifier 'FIPS_mode'" ; as LibreSSL did not plan to be FIPS compliant, i believe the problem came from that ?

Seconds, when invoking textproc/bat, it only display this message : "ld-elf.so.1: /usr/local/lib/libssh2.so.1: Undefined symbol "OPENSSL_add_all_algorithms_noconf" ... and again... OPENSSL symbol who is not covered by LibreSSL.

As i am not realy willing to go back to openSSL, how can i confirm that the problems came from LibreSSL ?
 
I don't have a solution for the ports you mention, but in general, using ssl=libressl is a constant battle in practice.

IMHO, the problem is the fact, OpenSSL API became the "de-facto" standard while being designed badly (so breaking changes happen quite often and all a consumer can do is checking version macros, cluttering the code), and LibreSSL tries to conform with it, but can never reach 100%.

Now, there are quite some projects that just refuse to accept LibreSSL compatibility patches. And there are port maintainers who refuse to maintain these patches locally (as part of the port). That's the reason why my local ports branch contains quite a few LibreSSL fixes that will never make it to main. When running into a problem, you can have a look there, if you're really lucky, I already have a solution ;) (careful, this branch is regularly rebased onto main).
 
karrakis said:
As i am not realy willing to go back to openSSL, how can i confirm that the problems came from LibreSSL ?
Click to expand...
There's an increasing part of software developers which simply does not care about being compatible to LibreSSL any longer for a bunch of reasons. Some of them even have already discontinued support for LibreSSL.

So expect this to become more and more an issue, stuff not working with LibreSSL any longer.
 
hardworkingnewbie said:
There's an increasing part of software developers which simply does not care about being compatible to LibreSSL any longer for a bunch of reasons.
Click to expand...
The #1 reason is the pain of cluttering your code with even more preprocessor checks (LIBRESSL_VERSION_NUMBER) than required for OpenSSL already, while all of this is a constantly moving target. That's understandable. The root of all evil is the bad API, so the obvious solution would be moving to a better API everyone can agree upon. In practice, it won't happen 😔
 
Zirias said:
I don't have a solution for the ports you mention, but in general, using ssl=libressl is a constant battle in practice.

IMHO, the problem is the fact, OpenSSL API became the "de-facto" standard while being designed badly (so breaking changes happen quite often and all a consumer can do is checking version macros, cluttering the code), and LibreSSL tries to conform with it, but can never reach 100%.
Click to expand...

Thank you for posting a succinct description of the real problem. It surprises me that more of the "open source" devs and ports maintainers don't realize that a de-facto security API is a potentially more serious issue than their support workload. It would seem that said API's bad design is in the same class of reasons that the LibreSSL fork happened in the first place. Ironic.

If there exists an option
Code: 
ssl=libressl
then I believe ports maintainers should include patches for this option. But failing that...

That's the reason why my local ports branch contains quite a few LibreSSL fixes that will never make it to main. When running into a problem, you can have a look there, if you're really lucky, I already have a solution
Click to expand...

Thank you very much (again) for providing this. I remember making a boost-libs fix like the one you have in the commit tree. From time to time I get this deep on a port since LibreSSL is what I use; would you accept pull requests or is this just your private repo? It would be nice to consolidate these fixes so maybe others would realize this isn't just going to go away.
 
Nasrudin said:
Thank you for posting a succinct description of the real problem. It surprises me that more of the "open source" devs and ports maintainers don't realize that a de-facto security API is a potentially more serious issue than their support workload. It would seem that said API's bad design is in the same class of reasons that the LibreSSL fork happened in the first place. Ironic.
Click to expand...
It's certainly a reason OpenBSD also designed a simplified API for the TLS usecase, a nice description is in this presentation: https://www.openbsd.org/papers/linuxconfau2017-libtls/#slide-3

But it doesn't help much in presence of a "de facto" standard, you must reimplement that to offer a "drop-in replacement".

Nasrudin said:
If there exists an option
Code: 
ssl=libressl
then I believe ports maintainers should include patches for this option. But failing that...
Click to expand...
Some do, some don't. I tried starting a discussion about it: https://lists.freebsd.org/archives/freebsd-ports/2021-October/000773.html
As you can see, there's very little interest.

Nasrudin said:
Thank you very much (again) for providing this. I remember making a boost-libs fix like the one you have in the commit tree. From time to time I get this deep on a port since LibreSSL is what I use; would you accept pull requests or is this just your private repo? It would be nice to consolidate these fixes so maybe others would realize this isn't just going to go away.
Click to expand...
A "pull request" (in github's sense) probably won't work very well on a branch that's constantly rebased. My current repository is just my "cloud backup" of my local branch, so I mostly work on it when doing another "bulk" build and it just contains what I personally need...

What you suggest would IMHO be a new project, and it would first require to think about a good process for maintaining it ... probably also a lot of work. Sure, it would be nice ... ;)
 
Zirias said:
Some do, some don't. I tried starting a discussion about it: https://lists.freebsd.org/archives/freebsd-ports/2021-October/000773.html
As you can see, there's very little interest.
Click to expand...
I have heard claims from a couple people that LibreSSL "lacks developers" and "is falling behind". Even if that is true, and despite the projects that are "no longer supporting LibreSSL", an alternative SSL methodology is crucial to those of us wanting to be more secure than the average linux box (which is not hard, but I digress).
Zirias said:
A "pull request" (in github's sense) probably won't work very well on a branch that's constantly rebased. My current repository is just my "cloud backup" of my local branch, so I mostly work on it when doing another "bulk" build and it just contains what I personally need...

What you suggest would IMHO be a new project, and it would first require to think about a good process for maintaining it ... probably also a lot of work. Sure, it would be nice ... ;)
Click to expand...

Saying "pull request" was, of course, not strictly accurate. Yes, a new project might be needed and it would be some work. I've no idea how to maintain it, but I suspect the number of forks of the ports tree is ever increasing and this project would contribute to that. I'll give it some thought, but no promises. ;)

Sadly, at first glance the most effective way to support LibreSSL is to provide patches to ports upstream, which is what is going on now.
 
Packaging software doesn't necessarily mean maintaining X using non supported libraries by upstream. If you're deadset on replacing OpenSSL you're probably going to have more success especially upstream by adding WolfSSL supported but expect it to be a long and bumpy ride.
 
Nasrudin said:
I have heard claims from a couple people that LibreSSL "lacks developers" and "is falling behind". Even if that is true, and despite the projects that are "no longer supporting LibreSSL", an alternative SSL methodology is crucial to those of us wanting to be more secure than the average linux box (which is not hard, but I digress).
Click to expand...
LibreSSL is backed up by the OpenBSD guys, so I don't think that they've got a lack of developers. In my opinion what we are observing is the outcome of different project goals and ways on how to manage a software project, with LibreSSL being more on the conservative side of things.
 
Unless it's changed recently LibreSSL is also extremely slow, I haven't looked at the code but I do believe that it doesn't rely on hardware crypto and that most(?) assembly code is disabled/removed.
 
diizzy said:
Unless it's changed recently LibreSSL is also extremely slow, I haven't looked at the code but I do believe that it doesn't rely on hardware crypto and that most(?) assembly code is disabled/removed.
Click to expand...
This is really not new that LibreSSL runs a lot slower compared to OpenSSL.
 
Not giving up on LibreSSL just yet. Yesterday, I learned 3.5 is the stable release now, but in our ports, we're still on 3.4. 3.5 is available as libressl-devel.

Now, why is this interesting? In 3.5, LibreSSL did the same opaquing of structs OpenSSL previously did. This means, the "API gap" is getting narrower again. Once 3.4 is finally gone, chances are better not to need patches for LibreSSL any more, and if they are needed, they will be smaller. Maybe this improves support for LibreSSL in FreeBSD ports again.

The reason we still have 3.4 is all the existing patches that must be updated for the transition. That's a huge amount of work :what:.

I just finished two commits myself in my ports branch, hoping to help getting this forward.
 
You must log in or register to reply here.
Back
Top