libsodium-net
libsodium-net copied to clipboard
adamcaudill
Project Status & Path Forward
CC: @fraga @bitbeans @BurningEnlightenment
This project has been sitting for too long, as is rather behind where it should be now. This is largely, if not entirely, my fault. Due to a lack of time, and rarely touching Windows, much less .NET - which has resulted in me rarely having time to work on this. All that said...
.NET Core Support
The changes just merged should at least get us closer to proper support, though .NET Core is moving fast, which is making it hard to keep up, and get this project supporting modern standards.
.NET Legacy
As we move forward with modern standards, we need to make sure that we don't leave pre-Core versions behind. We can't trade one for the other, we need to make sure that we are addressing them both in a reasonable way.
NuGet Package
The package setup is far from ideal, especially the way that the libsodium DLL is handled. Last I looked, the bulk of the blame is on NuGet for not handling unmanaged DLLs in a remotely reasonable way, but we need something better than what we have now.
File Copy Issues & Deployment
This is the biggest issue we have, other than keeping up with Core. A number of options have been discussed, and all seem to come with issues. We really need to make sure we have this problem solved once and for all. I really don't care how, just as long as we actually make the situation better, not worse.
Issues Triage
We have a number of open issues, we really need to get through them, and close those that don't matter anymore, and find a path forward on the issues that still need to be resolved.
Project Management
So far our policy has been simple: all changes go through a PR and at least one other person has to agree before it gets merged, and I do all releases so that I can sign the binaries. This worked well in the past, but as my time has diminished, it's led to issues. We need to come up with a management process to ensure that things don't get stalled because I'm tied up.
Thoughts:
- All changes should continue through a PR, with at least one other team member approving before merging.
- Ability to release needs to be rethought, so others can release besides me. Given the sensitivity of the library and its uses, this needs careful thought to ensure that it stays secure and we maintain trust in the releases.
Forks & Other Projects
We need to review forms of this project, and other .NET focused projects related to libsodium to make sure that we are trying to pull in improvements, and cover as many of the use cases as possible.
Overall
To keep things on track, we need to address these issues and have a path forward to keep the project from getting stuck and becoming irrelevant.
Additional note on paths forward:
@tabrath has forked the project (https://github.com/tabrath/libsodium-core) to support .NET Core. Ideally, as me move forward (especially now that we've added Core support), it would be great to see that project merged back into this one.
I looked at the progress you've done and I really don't see any reason for me to keep my fork active. The major difference between our projects right now is just the file structure (root solution folder with src and test folders as this is the Microsoft convention to organize projects at the moment, nitpicking really). Should I just shut down my repo (or point it here) and remove the nuget packages?
@tabrath If there are changes you'd like to see here, I'd be happy to accept a PR. Given the progress you've made, I'd be happy for you to be more involved with this repo.
As to the future, my suggestion would be: Once everyone is happy with where we are, and we get the next release out, update your README to suggest people use this version instead - that way if issues are found with your fork, everything is still in place to release updates until everyone shifts back to this version.
My goal and strong desire is that we all put effort into a single project, so that we have one solution that is evolving in a healthy direction, supported by as many people as possible. Fragmentation here just increases the odds of more bugs, and lower interoperability.
I want to thank you for the work you've done, getting a version that addressed a real need - something that took me far too long to do. After all, the goal is to make strong crypto available to as many developers as possible. I very much appreciate that you took the ball when we dropped it.
Our team is really caught in between @adamcaudill and @tabrath's repositories. Is there any plans on progressing towards the merging of these two repos?
All: I'm sorry for the current status of things around here. At this point I'm trying to actively recruit a new maintainer to lead the project going forward.