.NET 6 support
jedisct1 opened this issue · comments
Now that .NET 6 is out, does it have implications on the files we build?
Do we need to support new targets?
Use both .NET 5 and .NET 6 in the tests?
/cc @ektrah
I'm not aware of any significant changes in .NET 6 w.r.t. invoking native libraries. So I don't think we need to do anything here to support .NET 6. (All the NSec unit tests pass on .NET Core 3.1, .NET 5, and .NET 6 without any modifications.)
At the moment, we do a basic "sanity check" if the libsodium NuGet package fundamentally works or not. We could extend this to cover more .NET versions and platforms/distributions, but IMHO the basic check using .NET 5 is good enough (until .NET 5 reaches EOL).
FYI net6.0 is a LTS (like .Net Core 3.1), so if I were you I'd migrate to net6.0 and ignore net7.0 when it will coming...
| .NET 6.0 (recommended) | LTS Tooltip: Long-term support (LTS) releases have an extended support period (3 years). Use LTS if you need to stay supported on the same version of .NET or .NET Core for longer. | 6.0.1 | December 14, 2021 | November 08, 2024 |
|---|---|---|---|---|
| .NET 5.0 | Current Tooltip: Current releases have a shorter support period (18 months). Use Current if you want to try the latest features and a newer release is not available. | 5.0.13 | December 14, 2021 | May 08, 2022 |
| .NET Core 3.1 | LTS Tooltip: Long-term support (LTS) releases have an extended support period (3 years). Use LTS if you need to stay supported on the same version of .NET or .NET Core for longer. | 3.1.22 | December 14, 2021 | December 03, 2022 |
Dotnet core supports cross platform development.
Therefore, some Xamarin projects may use the libsodium nuget package on Ios or Android.
We encounter a problem when using libsodium on Android: Xamarin couldn’t find libsodium.so.
It seems like there is a problem in the nuget spec file: https://stackoverflow.com/questions/58891684/include-native-library-in-nuget-package-consumed-by-xamarin-android
Please correct me if I make a mistake.
@ForkBug The libsodium NuGet package currently doesn’t include a pre-compiled binary (libsodium.so) for Android. Adding that would require some work – including changes to the NuGet spec file, but that’s just a minor part.
(All of this is unrelated to the topic of .NET 6).
@ektrah I'm not at all familiar with NuGet (never even used it actually, )but I just had a couple of pull requests approved relating to android binaries. I'm not sure where you are with this item but if it's still outstanding perhaps you can make a new issue related to it and @ me with some details and I'll take care of the Android side of things if you like. If all you need is an easy way to make pre-compiled binaries for Android you can do that in master by running autogen.sh -s and then dist-build/android-aar.sh It'll produce an AAR with all the binaries you should want. If you want them organized in a particular folder structure it'd be too easy for me to hook you up with a custom script.
FYI I'm using .NET 6.0 with Sodium.Core. The project works correctly for AES-GCM on x32 and x64 on AWS Lambda and Windows 10. I also tried ARM64 on AWS linux but no luck. At first I was getting a TargetInvocationException because my build did not include the libsodium.so. I then pulled your code an rebuilt it in ARM64 and include the file but it did not work. Most of the code is way over my head but happy to help if you need me.
Can you clarify when you say ARM64 do you mean Android ARM64?
It was on AWS lambda. I'm not sure the linux build but can find out if you need it.
ah OK I'm really not familiar with .Net build systems at all I just showed up in the thread to offer support related to Android builds.
Got it. We are kinda a fish out of water running .net on Linux but it is faster than windows and we need the speed. May be a fringe issue for the group. Using the new arch (arm64) is touted as 20% faster than x64. We just wanted to try it out. Thanks for the reply.
Oh don't take my reply as a reply from the project. I am not a major contributor I just showed up to update the Android Build scripts and offered to help here if someone else can bring the ASP.Net knowledge to the table. If I had a lot of details of what you're doing we could probably figure this out but I'd be learning the build system aspect of things from scratch. I also don't have a lot of time to dedicate to this sort of thing for the foreseeable future (work tempo, I was on vacation when I did the build scripts.) I was mostly trying to figure out if you were directing your post to me specifically.
No I just put it here because it looked like the .net 6.0 update thread.
yeah it is, it's just you replied to a comment I made and mentioned ARM64 so I was trying to figure out if I could help. If someone more familiar chimes in they might be able to be of more assistance. If I get some time later what would help me try to help you is if you could make up a tiny .net project using the tools you're trying to use but with just enough code to test that libsodium works and make it available to inspect and play with. AWS lambda adds an extra layer of complication and annoyance to testing. Are you able to use libsodium with a similar project that just targets a regular linux box?
Ha! sorry about that. No we use it on x64 windows, AWS Linux 2 Elastic BeanStalk (In both Ruby and .net) and on AWS Lambda. All our arch's are x64 and it works great. AWS is pushing their Graviton procs so we are beginning to look at it.
https://aws.amazon.com/ec2/graviton/
It is a little unclear for me but my understanding is like Apple AWS is moving toward the ARM instruction set. As for a project, I'm happy to put something together but you'll need a AWS account to test it on Lambda.
I'm new to open source and wanted to learn it so we wrote our web app in ruby but I'm still pretty green (as you can tell with my original post location).
If is helps below is the kernel used on the machines. I'm pretty sure AWS is moving to straight Linux 2 over time.
https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimes.html
I'd recommend doing a toy project on a raspberry pi or similar to try and sort out getting ARM64 to work and then moving up from there to AWS Lambda.
AES-GCM is only implemented for CPUs with AESNI.
I just meant to make sure the library is correctly included as part of the .Net build process. I was thinking a project that just includes libsodium and calls init to show that the library works at a basic level and make it a bit quicker to mess around with. I'm sort of assuming AWS ARM64 boxes do support AESNI but that would be an excellent explanation for that part of the problem.
Speaking to the guys on the Sodium.Core board, they suggested that libSodium is not currently compiled for ARM64. Is that correct? When I pulled your tarball Visual Studio 2022 had not issue compiling ARM64. I'll look into raspberry pi but I've never used. I have an Intel Mac will raspberry pi emulate the ARM64 environment?
Also I post on the AWS board board about if the chip supports AESNI. My best guess is yes but I'm way out of my depth at this point.
A raspberry pi is ARM64, though as was pointed out it lacks AESNI so AES-GCM won't work on it with libsodium. It would be the cheapest solution that doesn't rely on emulation. You could also use qemu I have never done it not sure how well / fast it works. You could probably find a board that does ARM64 and has AESNI though my experience is that little arm boards other than raspberry pis tend to get little to no long term support and can be a real pain. So personally I'd use a Pi4 to make a tiny project just to confirm the library inclusion and dynamic linking stages work (ie that the so is bundled, it is the correct so, that your .Net app finds it and links to it properly and that the so itself is compiled correctly). You'll want to make sure you use a 64 bit OS for your testing (or maybe have two sd cards and confirm 32 and 64 bit separately).
Ok sorry I though that was targeted at AWS.
Qemu might be a heavy lift for me but I'll take a look. It could be fun to learn.
Well I suppose it is indirectly targeted at AWS. My suggestion is that you create a simpler scenario that replicates your problem as much as possible but is easier for you to troubleshoot. If you set up the raspberry pi project the same way you setup your AWS project and it doesn't work then fixing it likely will lead you to figure out how to fix the AWS project. If it does work then it might help you isolate where the AWS project is going wrong. Either way you should have an easier time figuring out all the different parts of the build process you're using so you can better reason about what's going on. Oh and the first thing I'd try to do is build the project on the raspberry pi then I'd try to cross compile and deploy to it in case that's where the issue is creeping in.