Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: ./configure --enable-distro must provide --enable-haproxy and --enable-quic #6834

Open
wlallemand opened this issue Oct 4, 2023 · 16 comments · May be fixed by #7314
Open

[Bug]: ./configure --enable-distro must provide --enable-haproxy and --enable-quic #6834

wlallemand opened this issue Oct 4, 2023 · 16 comments · May be fixed by #7314
Assignees
Labels

Comments

@wlallemand
Copy link

wlallemand commented Oct 4, 2023

Contact Details

No response

Version

88d2503

Description

Distributions which ship packages with wolfssl are building with --enable-distro, which does an --enable-all. However --enable-all does not activate --enable-quic nor --enable-haproxy. This would be useful to integrate this 2 options by default, so people could link their haproxy directly with the wolfssl of their distribution, and one could provide third-party packages linked directly with wolfssl.

The absence of these options in distributions are making the deployment and the built of packages more complex.

Having these 2 options for the next release could help deploying wolfssl in the next ubuntu version (24.04 LTS) to provide a serious alternative to openssl.

That's too bad because --enable-distro seems to activate the openssl compatibility layer, so it does not lack much things. Maybe everything from --enable-haproxy could be reintegrated in the compatibility layer directly.

Actual files list of the -dev package: https://packages.ubuntu.com/mantic/amd64/libwolfssl-dev/filelist
Build script: https://git.launchpad.net/ubuntu/+source/wolfssl/tree/debian/rules?h=applied/ubuntu/mantic-devel#n22

Reproduction steps

WolfSSL:

$ ./configure --enable-all --prefix=/opt/wolfssl/
$ make
$ sudo make install

HAProxy:

$ make  TARGET=linux-glibc USE_OPENSSL=1 USE_OPENSSL_WOLFSSL=1 USE_QUIC=1 SSL_INC=/opt/wolfssl/include/ SSL_LIB=/opt/wolfssl/lib/ ADDLIB=-Wl,-rpath=/opt/wolfssl/lib/'
$ sudo make install 

Relevant log output

HAProxy is not building because it lacks `--enable-haproxy`.
@wlallemand wlallemand added the bug label Oct 4, 2023
@anhu anhu self-assigned this Oct 4, 2023
@anhu
Copy link
Member

anhu commented Oct 4, 2023

Hi @wlallemand
Thank you for bringing this to our attention. I think we need to do some internal discussion. For example, not sure how this would affect our internal testing infrastructure. Please stay tuned.
Warm regards, Anthony

@anhu
Copy link
Member

anhu commented Oct 4, 2023

Hello @wlallemand ,

So I don't want to split hairs here, but the default configuration is

./configure

So, when a distribution uses --enable-distro they are already no longer doing the "defualt". They are also going to need to add a prefix as well. Would it be too much to ask them to also add --enable-haproxy and/or --enable-quic if they want it?

Respectfully, Anthony

@wlallemand
Copy link
Author

I get your point, but distribution maintainers tend to minimize the build option they use, because they want to use what is recommended by the project. For HAProxy packages in ubuntu/debian we had to set some options by default directly in the project because it didn't make sense for the packagers to add options that diverged from the default build.

I don't know why they are building with --enable-distro but from what I'm reading in the documentation it "Enable wolfSSL distro build." so we can presume that is supposed to be used for packaging in distributions? Maybe I misunderstand but that what I thought.

If you have to add every single build option of wolfssl in the package build script it's quickly unmaintainable. The build options of WolfSSL are complex and it's difficult to chose them without being an expert on the subject.

The packages in a distribution are kind of a storefront, it's better to put shiny features so people can see them! The QUIC feature is a major asset compared to openssl which doesn't include the feature for example.

If you don't activate a maximum of options in the distribution, the package is pretty useless in a lot of cases and people would still have to maintain their wolfssl build. It would be beneficial for the wolfSSL project to have a maximum of features activated in major distributions, so projects that want to use it only have to link with it. Nobody wants to maintain an SSL package in addition to their project. When you want to provide 3rd party packages, you try to only package your project and rely on the distribution for the dependencies.

@anhu
Copy link
Member

anhu commented Oct 4, 2023

Hi @wlallemand ,

you make eloquent arguments and I don't disagree with any of your points at all.

... they want to use what is recommended by the project.

I fully agree. As such, I as a single developer, a member of a wider organization, need to go back to my team to see if we actually do recommend these settings. please allow me some time to organize some internal communications. You will hear back from me early next we here.

Warm regards, Anthony

@wlallemand
Copy link
Author

I know that changing default options could be challenging from an organization point of view, thanks for taking the time to handle this!

Regards,

@anhu
Copy link
Member

anhu commented Oct 10, 2023

Now that #6841 has gone into master, I've checked and

./configure --enable-distro --enable-haproxy --enable-quic
make clean all check

...no longer fails.
I will now proceed to make --enable-distro pull in --enable-haproxy and --enable-quic
Please stay tuned.

@wlallemand
Copy link
Author

wlallemand commented Nov 3, 2023

Thanks for the feedback! By the way, the next ubuntu LTS will be frozen at the end of february 2024. It would be great if a new release is done with that before this date, so the package could be updated, or we would be stuck for another 2 years without this unfortunately :/

@anhu
Copy link
Member

anhu commented Nov 7, 2023

Hi @wlallemand ,

Can you provide some sort of assurance that if this work is completed soon, Ubuntu will take wolfssl?

@wlallemand
Copy link
Author

WolfSSL is already packaged in ubuntu https://packages.ubuntu.com/search?searchon=sourcenames&keywords=wolfssl . However it's not up to date with the 5.6.4 version. I'm not part of the ubuntu project and can't guarantee they will pick this version unfortunately. It's possible that it is already too late :/

It looks like the 5.6.4 version is already in debian experimental, but not in debian sid, that's probably the reason why it's not there yet.

https://packages.debian.org/search?keywords=wolfssl&searchon=names&suite=all&section=all

@wlallemand
Copy link
Author

It looks like 5.6.4 landed in the next ubuntu and debian:

@anhu
Copy link
Member

anhu commented Nov 17, 2023

Well, this is great news!! Thank you for letting us know @wlallemand

@anhu
Copy link
Member

anhu commented Jan 12, 2024

@wlallemand ,

if you look at our latest on master, --enable-distro now brings in QUIC, but not HAPROXY. This is due to HAPROXY needing secure renegotiation. We don't feel --enable-distro should enable secure renegotiation.

Let me know if this makes sense to you.

Warm regards, Anthony

@wlallemand
Copy link
Author

I don't see any reason for this to be needed by haproxy by default, we even set SSL_OP_NO_RENEGOTIATION in the SSL_CTX initilization with OpenSSL. And It's really not something which is recommended by default indeed.

@wlallemand
Copy link
Author

@anhu could the secure renegociation be disabled in --enable-haproxy so we can have haproxy by default?

@anhu
Copy link
Member

anhu commented Jan 17, 2024

An interesting proposal. You're saying for HAPROXY, we can leave secure renegotiation disabled. Please stay tuned. I will have a chat with my colleagues.

@anhu anhu linked a pull request Mar 9, 2024 that will close this issue
@wlallemand
Copy link
Author

Hello, Any update on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants