[Ada] Initial library support

[Irvise]

Description

The current Ada wrapper and its associated build scripts create a client/server setup/example. However, this is not enough (from my understanding) in order to easily consume WolfSSL from an Ada project. WolfSSL should be built as a library using the files already present in the wrapper. This commit adds an initial implementation of the library build script that should be usable for any Ada project. It is based on the current server build script.

However, some issues/limitations have to be mentioned. I am unsure about how the required Linker flags should be added. For library project in GPRBuild, the Linker package has no effect, as that is for the final executable. So I suppose the consumer of WolfSSL's library will have to add the specified linker flags.

Secondly, and in my opinion, most importantly, is how to properly handle the different WolfSSL configuration options within the GPRBuild script... I know that there is user_settings.h and that is what currently configures the build process and all the details, but I would prefer if that was not fixed to the provided file... Of course GPRBuild supports user defined options, but I am unsure on how to properly handle the many options that WolfSSL has. I am also including in this aspect the correct handling of the different architectures! For example, I would like to try and use WolfSSL with my new ESP32-C6 (RISC-V) chip :)

I also created an alire.toml file for WolfSSL that builds the different project files. It can be found below. Alire, for those that don't know what it is, is equivalent to Rust's Cargo or C++ Conan, a build/project manager. Once the library build option is finished I will publish the Alire recipe to the main repository for everybody's ease of use.

name = "wolfssl_ada"
description = "WolfSSL encryption library and its Ada bindings"
version = "5.6.6-dev"

authors = ["Fernando Oleo Blanco"]
maintainers = ["Fernando Oleo Blanco <[email protected]>"]
maintainers-logins = ["Irvise"]
licenses = "GPL-2.0-only"
website = "https://www.wolfssl.com/"
project-files = ["wrapper/Ada/wolfssl.gpr", "wrapper/Ada/default.gpr", "wrapper/Ada/client.gpr"]
tags = ["ssl", "tls", "embedded"]

executables = ["tls_server_main"]

Documentation will be filled once the scope is fixed and the library works as expected.

I am opening this PR to start gathering feedback and comments.

I am pinging @dgarske as the committer of the bulk of the bindings. I cannot find Joakim's Github user (if there is any).

P.S: this pull requests comes after a conversation that I had with Martin (from the UK division).

Testing

The current GPR file builds the .a library, no further checks have been performed.

Checklist

• added tests
• updated/added doxygen
• updated appropriate READMEs
• Updated manual and documentation

[wolfSSL-Bot]

Can one of the admins verify this patch?

[dgarske]

Hi @Irvise ,

Thank for the pull request. I will look it over and I also pinged Joakim.

I don't see a contrubutor agreement on file. Would you mind submitting a ticket to our support at wolfssl dot com alias referencing this PR?

Thanks,
David Garske, wolfSSL

[embhorn]

@Irvise has been approved as a wolfSSL contributor

[dgarske]

@joakim-strandberg any feedback on this? Seems like a nice Ada feature having wolfSSL as a library.

[joakim-strandberg]

Hi all! I saw this in my e-mail just now. @Irvise , great of you to push improvements of the Ada binding forward. I saw the recorded video you organized @Irvise a couple of days ago and was very happy to see that the Ada binding to WolfSSL was the first topic of the video chat meetup. The progress I made 7 months ago with the intent of including it in Alire can be found here: https://github.com/joakim-strandberg/wolfssl/tree/ada_windows_support/wrapper/Ada , maybe something can be reused for the Alire support you are working on @Irvise ?

[dgarske]

Hi @Irvise , what is the current state for this PR? Could you please rebase to latest master. I think that may help resolve some of the CI issues reported. Are you planning to add more to this PR?

[Irvise]

Hi @dgarske, I still could not find time to properly finish it. Sorry for the delay. I will nonetheless rebase it and try to get it finished in the next couple of weeks. I may restructure the Ada bindings as in Joakim's branch too. But that shouldn't affect the use/consumption of the binding.

Btw @joakim-strandberg, did you receive my reply? Sometimes my personal email address gets marked as spam :/

[dalybrown]

I totally didn't see this pull request. Great idea! I actually started doing the same thing ... whoops. I should probably look next time. I updated the Ada example to use DTLS here: #7397. I was going to make another pull request to make it an Alire project but you already started. I'm happy to help!

[dalybrown]

Some initial thoughts:

1. I think you should restructure the directory to better align the the alire project structure. (i.e., move the actual sources (wolfssl, spark_sockets to src/ folder.)
2. Move the examples to an examples/ folder so that you don't need to exclude those files in your project file.
3. Add an alire manifest to the root of this project where your project file will be.
4. You can use Alire + actions to generate the user settings file to only include the features you can. You can use alire variables to control what to enable/disable and tie those in with actions (which would call configure...). I didn't try this out yet but it was what I was thinking to try out.
5. You might have to break up the wolfssl bindings to separate files if you plan to generate the user settings file on demand. Otherwise, you'll have linker errors. You might want to simplify how much configuration you give clients as a starting point (e.g., TLS, DTLS can be separated, but not the individual versions).

[joakim-strandberg]

Thanks for your feedback Daly and your work on the support for DTLS. On Saturday April the 6:th of April 15:00 Central European Time (https://forum.ada-lang.io/t/ada-monthly-meeting/384/41) at the Ada monthly meeting the wolfSSL Ada binding will be discussed. It would be great if you would have possibility of joining too.

[dalybrown]

Thanks for your feedback Daly and your work on the support for DTLS. On Saturday April the 6:th of April 15:00 Central European Time (https://forum.ada-lang.io/t/ada-monthly-meeting/384/41) at the Ada monthly meeting the wolfSSL Ada binding will be discussed. It would be great if you would have possibility of joining too.

Ahh I'm away this weekend so I can't attend unfortunately. Happy to help otherwise.

[Irvise]

Hi @dalybrown

1. I think you should restructure the directory to better align the the alire project structure. (i.e., move the actual sources (wolfssl, spark_sockets to src/ folder.)
2. Move the examples to an examples/ folder so that you don't need to exclude those files in your project file.

Will do :)

4. You can use Alire + actions to generate the user settings file to only include the features you can. You can use alire variables to control what to enable/disable and tie those in with actions (which would call configure...). I didn't try this out yet but it was what I was thinking to try out.

I was also thinking about that, but I am not sure how ergonomic this will be. But I have to give it a try nonetheless!

5. You might have to break up the wolfssl bindings to separate files if you plan to generate the user settings file on demand. Otherwise, you'll have linker errors. You might want to simplify how much configuration you give clients as a starting point (e.g., TLS, DTLS can be separated, but not the individual versions).

Yes... I am aware of the linker issues... I agree with your approach to limit the options to only the major features.

I will hack a bit on this and see what I can come up with :)

Cheers,
Fer

[Irvise]

An update from my side. I managed to create a test submission of WolfSSL to the Alire index, see alire-project/alire-index#1023. This demonstrates that Alire does work correctly even with the current project structure.

I will wait for #7397 to be finished before continuing :)

[dalybrown]

This is being nitpicky, but, is the _ada really necessary here? By virtue of being an Alire crate, the ada part is implied.

[Irvise]

Makes sense. I will take out the _ada surname :)

[dgarske]

FYI: @Irvise , we have merged #7397. Looking forward to your continued work on this. Thank you, David Garske, wolfSSL

[Irvise]

I will get back to this PR then :) But I will not be available for the next week, so it will take a bit longer than I had wished for. I will also try and see if I can catch the Windows warning reported in #7397

[dalybrown]

I will get back to this PR then :) But I will not be available for the next week, so it will take a bit longer than I had wished for. I will also try and see if I can catch the Windows warning reported in #7397

I'm happy to help. (Although, the next few weeks are also busy for me ... so i'm not sure how much time I can contribute right away.)

[Irvise]

Well... It is better late than ever I guess...

I finally took some time to take a final review at the PR. I have documented Alire in the README for the Ada wrapper and I have manually verified that SPARK still passes all checks with the latest version (14.1.1 currently).

I have been thinking about how to make DTLS optional... For the time being, I would just simply let it be built by default, when someone needs to turn it off, maybe then the work could be done :) What do you think?

Nonetheless, here is the approach I would follow in order to truly make it optional. I would use the separate keyword in order to split the actual implementation of the DTLS functions, see this recommendation from GNAT and the Compile_Time_Warning pragma. Then use GPRBuild with its flags to select the correct or empty implementation. It may require a child package just for DTLS, but I think it is doable. What is your opinion @dalybrown?

I think that the AdaCore community toolchain section could be fully deleted from the README, do you agree @joakim-strandberg?
Also, since the latest SPARK/GNATProve version, SPARK is able to more or less prove the existence and correct handling of exceptions, see Exceptional_Cases. Should we update the README to reflect that? Basically, by just deleting the final paragraph about SPARK not handling exceptions.

Edit: turn DTLS on -> turn DTLS off

[dgarske]

Thank you @Irvise
Okay to test. Contributor agreement on file.

[joakim-strandberg]

Thanks for reviving this pull request @Irvise .

I would use the separate keyword in order to split the actual implementation of the DTLS functions...
I agree. I would prefer using separate over child packages to achieve optional implementations.

I think that the AdaCore community toolchain section could be fully deleted from the README, do you agree @joakim-strandberg?
I agree.

Also, since the latest SPARK/GNATProve version, SPARK is able to more or less prove the existence and correct handling of exceptions. Should we update the README to reflect that? Basically, by just deleting the final paragraph about SPARK not handling exceptions.
With the new capability of SPARK the README needs to be reviewed. Totally OK by just deleting the final paragraph.

[Irvise]

Thanks for your feedback @joakim-strandberg. I have updated the README to reflect the changes.

[dgarske]

Okay to test. Contributor agreement on file. Thank you @Irvise